Last week was CES, the Consumer and Electronics Show held annually in Las Vegas. Amid the usual breathless fawning over TV’s that were a bit bigger (and everything else that was a bit smaller) than the same time last year, newspapers and tech blogs were falling over themselves to show the Cube, “the first 3D printer designed for your home”. Sorry, that should be the Cube™, because 3D Systems have evidently come up with such a great name, they want to make sure everyone else knows they’ve trademarked it.

The Cubify™ Cube™ © 3D Systems®

Journalists and bloggers who are more used to writing about the latest cellphone have at least some excuse for merely repeating the claims of the Cubify press release without really understanding what they’re writing. Journalists and bloggers who write about 3D printing have no excuses. But what amazed me, when reading about the launch of the Cube (and Cubify, the ecosystem which surrounds it), was how accepting and uncritical the reports were (Fabaloo was a notable exception, and at least asked some questions, even if the answers weren’t available). It’s like no-one ever heard of Shapeways, or Makerbot, or iMaterialise or Fab@Home, or any of the other machines and systems which have preceded the Cube. So, here’s a rather more critical report on 3D Systems jump into the consumer market.

The Cubify website and service is still in beta, so it’s difficult to judge some of the elements. Still, most of last week’s press concentrated on three areas: the printer, the prints it produces, and the community who will start using the service, so I’ll do the same.

The Printer

One of the things that really surprised me about the Cube launch was how no-one picked up on its ‘similarity’ to the Up! printer.

The Cube © 3D Systems

The totally unrelated Up! © Delta Micro Factory Corporation

No-one except Up! printer users that is, who were wondering at 3D Systems’ “blatant copying.” I appreciate irony, and the fact that a Chinese company is being ripped off by an American one does strike me as kind of funny. But what’s sad is that a machine which is supposedly the first 3D printer for your home is so boring, and so poorly considered. I don’t think anyone would claim the Up! printer is a thing of beauty – it’s brazenly utilitarian and clearly looks more suited to a garage or workshop than a home. But at least it’s honest. Whereas the Cube is basically an Up! printer, shrink wrapped in plastic with a few fillets applied, masquerading as a consumer product. It doesn’t try to reconsider what a 3D printer could look like, how it might relate to and be perceived by its users (unlike the Origo, for example); and it certainly doesn’t consider the environment it’s supposedly designed for. Is the Cube meant to go in the bedroom, the kitchen, the study, the bathroom? From it’s design, I’ve no idea.

© Origo

In other words, the Cube doesn’t push the boundaries in any sense. Except one, which is that the Cube is the only low cost 3D printer which uses cartridges instead of a spool of material. Admittedly it makes the product look less like a kit of parts, though the claim that this makes the material easy to load might be questionable – as far as I can tell the material still needs to be threaded to the print head nozzle. What it does offer, of course, is the possibility to restrict the use of third party material suppliers, in much the same way that manufacturers of consumer ink-jet printers do. This is standard practice in the world of expensive machines that 3D Systems comes from, and it may explain how they’re able to sell the Cube at $1299, a relatively low price compared to rival machines. At the moment Cubify is offering a single cartridge at $49.99; there’s no indication of how much material a cartridge holds, but it looks much thinner than a standard 1kg spool, which typically retails for about the same price. If that is Cubify’s business model, it will be interesting to see the extent to which it’s accepted, especially by the potential market who are yet to purchase a 3D printer.

It’s that potential market which also makes the final point about the design of the printer interesting. Without exception, I’d suggest, all machines  currently on the market that might be considered rivals to the Cube are what can be described as ‘hobbyist’. Some, such as the Rep Rap incarnations, are open source, others are not, but they all assume that the person using the machine will have the interest (and skill) to tweak and modify the machine’s performance, either through software or hardware (and typically both). Even the Up! printer, which most people claim is the closest anyone’s got to an ‘it just works’ device, has discussions on its message boards about calibration, nozzle temperature and hacking the speed of the onboard fan. Amongst the general population who actually know what 3D printing is, I’m sure there are some who would like to get involved, but are put off by the expertise needed to get a machine up and running. A true ‘plug-and-play’ 3D printer would likely attract a lot of customers, but the question is whether the machine will live up to that reality. If it doesn’t, I suspect that 3D Systems’ will have a lot of disgruntled users.

The Prints

Cube sample prints © 3D Systems

Cubify claims a Z-axis layer thickness of 125 microns (0.125mm), which if achievable is very good. Most printers in the same market space achieve somewhere between 0.2 and 0.3mm. But is it realistic? The press release image above is one that I’ve seen on a lot of different websites, and the printed objects don’t look bad, even if (or maybe because) they are out of focus. But here’s one that got much less publicity:

Cube sample print © 3D Systems

I think it was also a press release image, though I can’t find it on the Cubify site now. And to be honest that’s not surprising, because if that’s the quality that the Cube can achieve, it’s very disappointing. It’s certainly not up to the standard that can be achieved with other machines, and what’s more, because the Cube is a closed system, no-one will have the options to improve the print that they might have with a rival printer. Here’s another image, showing the Cube in action at CES, and it’s even less impressive.

Cube sample being printed at CES © The Verge. Click for larger image

I’m not sure why these prints are so bad, given the claim of a Z-axis resolution of around double what the Cube’s rivals can achieve. Maybe the XY-axis resolution is much poorer (it’s not given in the specification). Maybe the printers themselves should still be considered as beta releases, and when they’re launched we’ll see much better results. What’s clear is that the specs won’t count for much if the machines can’t deliver.

There were a number of samples on show at CES which were much better quality though. Here’s one, a shoe from Freedom of Creation:

Not a Cube sample © The Verge. Click for larger image

The reason it’s much better quality, of course, is that it wasn’t made on a Cube printer. Not being at CES, I have no idea how these products were being talked about. But I’ve seen them on a number of websites where there’s no indication that they were made by an entirely different machine and process. This image is from The Verge, which shows it alongside prints which did come from the Cube, under the headline “Cubify 3D printers and product sample images.” And here’s a CNET interview with Rajeev Kulkarni of 3D Systems, who does a very poor job of explaining the difference between the product samples he’s showing.

To be clear, I’m not trying to suggest that this was a deliberate ploy by 3D Systems. I’m certain it was much more to do with a poorly conceived and naively executed communications strategy. But this is one of the big hurdles that 3D Systems is going to have to overcome. The company is used to dealing business-to-business, with one-to-one interactions between sales staff and purchasers, many of whom have ongoing relationships. Generally the people buying the machines won’t be spending their own money, and may not even be the ones who actually use the machines. Dealing business-to-consumer is altogether different. Right now I don’t see much indication that 3D Systems fully grasp that.

The Community

I’ve been involved with a number of companies who’ve moved from a focus on technology to a focus on consumers; some of them have done it well, and some have done it shockingly badly. The very worst have seemingly no perspective about how they are perceived, and come across embarrassingly like your dad trying to talk like a teenager to impress your sister’s girlfriends. Does anyone other than 3D Systems think that LL Cool J is cool any more?

It’s hard enough when all you’re trying to do is make your product appeal to an audience you’ve never engaged with before. It’s even harder when you feel the need to build a ‘community’ around a name that no-one’s ever heard of. 3D Systems have jumped right in, with not entirely convincing results.

“Absolutely loved sharing my ideas with the Cubify™ community and making my dream of creating my own toy come true! Cubify™ rocks!”

says Max Freeman, who apparently uses TM symbols in every day speech. Over on the ‘Community’ page, a wall of mostly blank faces is punctuated by Deelip Menezes, who tells us

“I love my woman, my wine and my work, not necessarily in that order.”

Wow, you’re so, like, awesome Deelip. What you don’t tell us though, is that you’re actually a Cubify employee. Oh, and you’ve trademarked your name.

The Cubify Wall © 3D Systems. Click for larger image

My point here isn’t just to take the piss. It’s to show how easy it is to ridicule attempts to engineer ‘community’, especially when they’re bogus. And I’m not the only one to spot it, in fact my attention was drawn by this post on Core77, where the author, talking about the Cubify community wall wonders about being

“met with a pointless wall of headshots of different users, and many of them stock silhouettes to boot. Am I meant to click on people’s faces that I like in order to see what they’ve made?”

It just feels so false, so like a big company trying to get in on something that’s still relatively unknown, but without any real understanding of what that ‘something’ is.

The Core77 post also picks up on the Cubify Store, and it’s here that the ‘community’ idea really starts to be stretched thin. On Core77 the author compares the store to Thingiverse, where members upload designs and share them for free. That’s not to say that an open source approach is the only valid one, Shapeways and Ponoko have vibrant communities of users, some of whom sell their designs and some who make them freely available. But on Cubify, the only option is to sell your work, either that, or don’t share it at all. And it’s not only model files for 3D prints, there’s even a section where you can buy pictures of models of 3D prints. It all seems so desperate, so money-grabbing, and so predictable. I can even picture the meeting in some bland, reservable-on-Outlook meeting room where people got ‘energised’ as they ‘thought outside the box’ on ways to ‘monetize the offering’.

But maybe none of this matters, maybe the experience of using Cubify to upload and buy a model is so great that it blows all the already existing systems away. Surely that was a possibility? And so I signed up to try things out: here’s the page I was presented with when trying to upload a part:

Cubify model upload © 3D Systems. Click for larger image

There’s a few mandatory sections to fill: the name, the category of product, the units of measurement etc. Another compulsory section is the price, but since I didn’t want to offer my model for sale I put in $0.00. But this isn’t allowed, the minimum price I can sell my model which I don’t want to sell is $4.99. Even deselecting the ‘Sellable’ checkbox and choosing ‘Private’ as the model’s status doesn’t change this. There’s more compulsory sections: a short description, a long description (my long description of a product I don’t want anyone else to see or buy was shorter than the short description, but apparently that’s okay), and tags. Finally, I got to choose the model file I wanted to submit, and hit send. But there’s a problem – it’s also compulsory that I provide an image (of a model I don’t want anyone else to see or buy). No automated image generation, let alone an automated interactive model, like you’d see on Shapeways or Google 3D Warehouse. And so at that point I gave up. In any case, from the models on show in the gallery at the moment it seems the only material options are ‘strong white plastic’ and ‘glossy smooth plastic’. No, I don’t know whether that’s ABS or nylon or PMMA, it’s all the same isn’t it?

Conclusion

3D Systems aren’t Apple, that’s obvious. In truth, they’re not even LG. To the vast majority of people outside the additive manufacturing industry, 3D Systems are totally unknown. On the one hand that’s a bad thing, but on the other it’s an incredible opportunity. It means that 3D Systems had the chance to create a brand that could be absolutely anything they wanted, in tone, in appearance, in its offering and promise. Judging by the Cubify website, what they wanted was David Brent.

Cubify pre-launch teaser © 3D Systems. Click for larger image

The way to launch a product successfully isn’t difficult to understand, though obviously it can be difficult to achieve. There’s three stages: build-up, launch and sale, and three tasks: build the hype, over-deliver on the hype, sell. Apple are masters at this cycle by building excitement without revealing what the excitement is about, then showing something that surprises everyone, and then by making it available to buy the next day. If you look at some of the pre-launch PR that 3D Systems were putting about before CES you’ll see that’s what they were trying to do. But it failed, for easy to understand reasons. Everyone knew what 3D Systems were going to be showing at CES – they’d already shown pictures of the Cube and told people what it was. There was no spectacular wow that nobody was expecting. There wasn’t even an award, despite concerted efforts to get people to vote for a product they’d never used, as if winning somehow proved something. Although actually a 3D Printer did win an award – the Makerbot Replicator took ‘Best Emerging Tech’, though you wouldn’t know it from the Cubify blog, which seems to be claiming it won four awards including ‘Best of Show’. [Edit: the blog entry has changed to read "4 Awards and/or “Best of the Show”] And what if you actually want to buy a Cube printer? Cubify will be “taking orders soon”. I sense a deadline that was decided a long time ago, and a project that failed to deliver.

Makerbot Replicator two-colour printer, which did win an award at CES © Makerbot.
Click for larger image

If you’ve looked at the Cubify website you might have noticed one area that I haven’t touched on, which is the Cubify API. This is the part of the 3D Systems launch strategy which really confuses me, because in there are the ideas that might really be different, that might really change things. As far as I can tell, the concept is to offer a platform where developers can create apps which allow consumers to modify or create 3D models. A bit like the i.materialise Creation Corner, but on a much bigger and more open scale. Instead of just being able to upload models, there would be the option to upload modelling tools, and to earn revenue every time someone used one. For the consumer, rather than just choosing a model, you’d choose a model and then choose from a menu of apps giving you different ways to customise it. But where is the fanfare around this idea? Most of the API page isn’t even ready, there are no apps available in the store, and the only example isn’t on the API page, but the ‘Creative Partners’ page. It’s hardly surprising that almost no-one is talking about this aspect of Cubify.

And so, finally, what about all those TM signs? You might have noticed in this post that they annoy me, and I’ll admit it. If you go to the Cubify home page you’ll see 10 of them, including one claim, apparently, to have trademarked ’3D’ (though the USPTO have no record of it). I’ve no idea how many there are across the whole site. What annoys me is it’s so corporate, so desperate to grab IPR, whilst at the same time trying to appear cutting edge, as if ‘Cube’ is a word that the rest of us will all be wanting to copy. On the one hand trying to build a ‘community’ and on the other saying “don’t touch our property”. The result is it comes across as not having a clue. There’s no requirement to display a TM sign for the mark to be protected, so why are they there? I really pity the industrial designer who has to design the next model of printer. Because I know, without a doubt, somewhere in the brief there’ll be a line that says something like “our community love the Cube™”, and no hope of doing anything that isn’t.

Like most designers, I suspect, I have fond memories of Lego as a child,  and so it seemed somehow appropriate to be playing with the Lego Digital Designer over Christmas. Unsurprisingly, I never had any real expectation of being able to design a working computer mouse in Lego, and the Digital Designer clearly isn’t a CAD system in any sense that the term is usually understood. But as cheap 3D printers start to become mainstream, the need for 3D modelling software that can be understood by non-experts becomes more and more necessary. TinkerCAD is perhaps the ‘simplest’ system available currently, but it’s still recognisable as fitting into the traditional 3D CAD paradigm. Lego Digital Designer doesn’t, and that’s what makes it interesting, even if, as I found, there are a number of flaws in its implementation.

Lego Digital Designer Intro screen © Lego

Lego Digital Designer runs as an installed application, and is available for free download for Mac and PC. Once installed it will run without an internet connection, but when connected it automatically updates the bricks that are available, and access to the Lego website is needed to check the cost of any model you design. This leads me to one of the first notable aspects of the software, which is that the Design byMe side of things is about to close. Design byMe is the part of Lego Digital Designer which allows you to ‘manufacture’ custom kits, complete with customised building instructions andboxes. According to Lego’s press release the system was too complex for children and “struggled to live up to the quality standards for a LEGO service.” Many posters to the Design byMe message boards suggested the real issue was the high cost of custom kits compared to standard Lego models, ie less to do with complexity and more to do with cost, and so it will be interesting to see what the future of customised Lego will look like.

The Lego Digital Designer site has 11 videos to introduce the software and demonstrate how to use it. All are about 2-3 minutes long and very easy to follow, though the last two are more of a re-cap and don’t tell you much that’s new. When you launch the application you’re first asked to choose which ‘environment’ to work inside: Design byMe as already discussed, Mindstorms or Universe. Different bricks are available depending on which one you choose, though the modelling environment is the same. One of the first things you notice is how CAD-like the layout is – a tool palette down the left-hand side (this can be dragged to expand) of the modelling window, ‘Select Filter’ and ‘Manipulation’ palettes at the top, and the ability to create templates and groups, which are essentially sub-assemblies. The mouse scroll wheel is used to zoom and the right mouse button to rotate (RMB + shift allows you to pan).

The brick palette in the Lego Universe environment

The palette of bricks available is organised into sub-groups which can be opened and closed to reveal their contents. Bricks can be filtered by shape, colour or set, and the number of bricks shown can be significantly reduced by showing only one of each colour (rather than, for example one shape of brick in 12 different colour options). Nonetheless, especially when you first begin to use the software, the number of bricks available is daunting, and it takes a considerable amount of time to learn which sub-group contains which particular brick. This can lead to a lot of time spent scrolling through the bricks trying to find the one you’re after, and it becomes even more frustrating when the brick you’re looking for isn’t obvious because it’s icon has been drawn from an angle which doesn’t show certain details. I also found it strange that some sub-groups contained only a few bricks (I think the smallest number was five) whereas others contained hundreds. I’m sure this is probably to do with an identification system which exists in the  physical Lego world, but within the software it makes for poor interface design.

Bricks are placed by selecting from the palette and then clicking in the build area, which automatically expands as the size of the model grows. Bricks are rotated using the arrow keys, which doesn’t always work how you might expect, but generally it doesn’t take long to get a brick in the orientation you want. As the model begins to build, previously placed bricks highlight where a new brick will locate, and the appearance of a new brick greys out if you try to place it in a position that isn’t (or wouldn’t be) physically possible. As might be expected, bricks ‘snap’ into place, though I’d describe this as a ‘soft’ snap rather than an assertive ‘click’. Particularly with the Lego Technic type bricks, which don’t always locate in the same way as conventional bricks, the way that parts snap to each other can cause problems. A shaft will snap to a hole for example, or a gear wheel to a shaft, but the only way to position the shaft in the hole is by eye; this can cause a lot of headaches, as I’ll explain later.

As new bricks are placed their interaction with other bricks is highlighted

Within the build area there are a number of tools for selecting and manipulating bricks. Along with the regular select tool there is a multiple select (incrementally adds to the selection as bricks are clicked) and the ‘connected’ select tool, which selects all the bricks that are joined to the one you click. This last tool is a lot less useful than it might seem, because in most models all the bricks will be connected; in fact most of the time I found myself using only the regular select, since Shift-clicking alternate bricks works in the same way as the incremental select. The colour selection and shape selection tools I didn’t use at all. One tool that is extremely useful though, is the Clone tool, which basically copies existing bricks; I found myself using this all the time rather than trying to find a brick I’d already used from the main palettes. The paint tool allows bricks to be painted and works in different ways depending on which environment you’ve chosen to work in: within Design byMe it will only allow you to choose the colours which correspond to bricks in the ‘real’ world, whereas Universe allows you to choose any colour from the full Lego colour palette.

Bricks can be painted using colours from the Lego palette

In order to start testing the software properly I went to the Design byMe gallery page to look at creations uploaded by other Lego users. Models are arranged by themes and other users can vote on how good they rate the design, furthermore all models are available to download and recreate or modify. To be honest, the implementation of the gallery is pretty poor (or, perhaps, simply showing its age); images are small and static, descriptions are sparse and there’s no opportunity for users to discuss each other’s models. As such it’s much less vibrant than the equivalent galleries of Shapeways or Ponoko, to name just two. There’s also a lot fewer models than I was expecting. In part I suspect this is because there are a number of different Lego sites where you can upload models (Lego Creator, Lego Club Cool Creations, Lego Hero Factory, etc), which doesn’t make for a particularly seamless or comprehensible experience. But if you are able to find models you like, they’re easy to download (models are generally less than 100Kb in size) and often of a high standard. There’s also a built in tool which will generate an interactive building guide, which makes it much easier to understand how the model should be constructed. The model I chose to start with was this T34 tank, built by thepizzaman12, shown below.

T34 tank downloaded from the Lego Design byMe gallery

Whilst it was fun in the beginning to analyse the model and begin to recreate it, the process quickly highlighted some of the flaws in the Lego Digital Designer system. To start with, as already mentioned, simply identifying which bricks had been used was quite a problem. The building guide, unlike a traditional paper version, is animated and allows you to rotate the view, which makes it a lot easier to recognise the brick you’re looking for. But finding one brick among a menu of hundreds, some of which are quite similar, isn’t a particularly enjoyable task. Within a model, clicking on a particular brick displays its description and code number; unfortunately this doesn’t happen in the building guide, and it’s not possible to have two files, or two instances of the software, open at the same time. The other problem was the automatically generated building guide, which whilst being a fantastic idea, unfortunately works at quite a basic level. On the tank example shown here, each link element of the track is made up of 6 individual Lego pieces, each track contains 45 links, and obviously there are two tracks. The building guide turns this into 178 steps, 175 of which are repetitions of the first three instructions.

The next problem caused me to abandon the model and start on something else. Having built one of the set tracks, I found the very last piece (a pin through four holes) wouldn’t fit. It was fairly obvious that the holes didn’t line up, and I couldn’t work out how to make them do so. Not knowing why the model wouldn’t work, I thought perhaps it was because this wasn’t an ‘official’ Lego model, and that maybe the model I’d downloaded had been fudged to look like it fitted together, even though it didn’t. I know now that this probably isn’t the case, but it took a while longer to find out.

Lego Technic Compact Excavator © Lego

Since I wasn’t able to remodel the user-designed tank, I decided to try an official Lego model, and went for the ‘Compact Excavator’ which is part of the Lego Technic range. This was chosen primarily because the original building instructions are available to download, though I later discovered that, in fact, it’s possible to download almost any instruction manual for models sold after 2002 (you have to go through the ‘customer service’ web page, rather than the product page). I also wanted to see how well the software handled the moving and interlocking parts which are a feature of the Technics range.

I started by trying to model the excavator in the Design byMe environment, but it quickly became clear that most of the bricks I needed were unavailable. Restarting again in the Universe environment gave me access to all the bricks, but on starting to build the model I got a warning that the model contained bricks which couldn’t be price checked or uploaded to the online gallery; this also means that the model wouldn’t be able to be purchased. I’m not sure why only certain bricks are available for custom kits; searching through the message boards there are occasionally complaints but never any real explanation.

In all I spent about five hours working on this model, spread over a few lazy Christmas days. To begin with everything was fine, but the first problem I came across was some of the parts weren’t available. I think this may be because the model is no longer sold, but the parts needed to make the caterpillar tracks aren’t in the brick palette as far as I can tell. This was annoying, but not too much of a stumbling block. The next problem was far more of an issue, at least as far as a working ‘CAD’ system is concerned.

Lego Technic models are designed with a lot of parts which pass through each other (shafts, pins, etc) or dynamically interact with each other (gears, levers, etc); this is unlike most other Lego models where bricks snap together and then remain static. In the software parts will ‘snap’ to each other, but this only works well in the static sense. In a situation where there is no definite position (a gear wheel on a shaft for example), the only way to position the gear is by eye. And in a complex model (which all the Technic models end up being) this causes problems downstream. Because that gear, which is slightly out of position, has to interact with another gear, and if the teeth overlap even slightly, the software won’t let you place it.

In this image the red brick has been placed on the shaft

However the software will not allow it to be moved to the correct position

Lego Digital Designer has a couple of tools which can be used to address this problem, though their usefulness is questionable. The first is the ‘hinge’ tool, which rotates one brick about the axis of another that it’s joined to. In the tutorials this is illustrated by opening a door, but it can equally be used on parts that aren’t really hinges at all. Two gear wheels with overlapping teeth, for example, can be ‘hinged’ so that the teeth interlock. And so by fiddling around with the hinge tool, parts which will not place correctly can be wriggled into place.

Using the hinge tool the red brick and gear wheel are rotated slightly

This allows the red brick to be moved into position

Whilst this may seem like a useful, if haphazard, solution, the problem is that as the model becomes more complex, the hinge tool works in increasingly unpredictable ways. I experienced a number of instances where it seemed impossible to get the parts to hinge how I wanted, and instead the model rotated about a completely unrelated axis. This problem was even worse when using the ‘hinge align’ tool, which is supposed to tell two parts that they share an axis, and to align themselves accordingly. I think I managed to get this tool to work twice, but only in very simple situations where it was just as easy to position the parts manually. In most instances it either refused to acknowledge the parts could be aligned, or failed – in the most extreme cases this meant the whole model deforming as if it had been sat on!

When trying to ‘hinge align’ the red strut, the model deforms © Lego

The final frustration came when I thought I’d finished the model. Having spent a lot of time tweaking the position of parts in order to get as close to a finished model as possible, I’d finally reached the end of the manual, and saved the model. But when I later came to open it again, I got a message saying that two bricks were incorrectly positioned and had been removed from the model. And so I placed them (and tweaked them with the hinge tool) again, and saved, and got the same message again when I re-opened the part. And here I had a somewhat unexpected realisation, which was how disappointed I was at the model not working! It was a bit like having made the whole Lego kit in real life, only to find one of the last bricks is missing. That one missing piece spoils the whole experience of having built the rest of the model.

The final model (minus caterpillar tracks)

A warning that incorrectly placed bricks have been removed

I realise that these complaints make it sound like I have a highly negative impression of the Lego Digital Designer, which would be unfair. In many ways the software is very good: it downloads and installs quickly and easily, it displays well even on low end graphics cards, and it’s incredibly intuitive to just start picking bricks and assembling them. And it’s perhaps the case that when the system was first conceived, it was never anticipated that it would be used to build complex models. But on the other hand Lego should know, from their wealth of experience with Mindstorms, that people love to play, to push systems beyond where they were first meant to be. Lego’s press release says that the reason for discontinuing the Design byMe service is that it was too complex for children, and that’s left a lot of people on Lego’s message boards wondering if the Digital Designer system will be simplified and ‘dumbed down’. I’m not a hardcore Lego fan by any means, but I think it would be a great shame if that were the case. For some children, this might be the first ever experience of 3D modelling software.

Carrying on from the previous posts concerning D.I.Y. design, this entry looks at my attempts at using Cosmic Blobs to create a new design for a computer mouse. It’s far shorter than the posts dealing with SketchUp, because frankly it became apparent very quickly that there was no way Cosmic Blobs was capable of the kind of modelling needed to create a functioning consumer product. Nonetheless there are some interesting concepts behind some of the tools which could certainly be interesting for anyone considering the design of ‘consumer-CAD’ software.

Cosmic Blobs was a software package aimed specifically at children (though I’ve not been able to find anywhere that states what ages that was meant to include), developed by Dassault Systemes. Unfortunately it’s no longer available (although copies sometimes appear on Ebay), having been discontinued in 2007; this means there is no longer any support and none of the official documentation and tutorials are available. It also means that, despite being unlike any CAD software you’ll have ever seen before, the user interface already looks old. You’ll need Windows XP to run it (at least, it wouldn’t work on my machine with Vista installed), but it felt very sluggish to me.

Cosmic Blobs Lab Rat Edition © Dassault Systemes

Since there’s no official documentation available (the installation CD has no manual, and the online tutorials no longer exist) I had to rely on user-generated content to learn the software. But there is very little available, and if it weren’t for one particular source I would probably have given up trying. Luckily I found this set of tutorials, by a guy called Tom Meeks, who still maintains the Blobfans blog. The tutorials go through each tool and give some tips and tricks, as well as pointing out some of the limitations of the software, and Tom Meeks’ enthusiasm for Cosmic Blobs shines through.  Unfortunately though, about half the tutorials are dedicated to the painting and animating functions of the software, which I had no use for, so after a morning watching the tutorials, I was pretty much on my own.

The User Interface (click for larger image)

The first thing you notice on opening the software is the unconventional desktop you’re presented with. It certainly doesn’t follow many conventions for good UI design, which on the one hand I found refreshing, but on the other became incredibly annoying at times. As an example, at the bottom right (next to the copy icon which shows one tree becoming two trees), there is a screw-head. This is actually a button which turns the surface triangles view on, but there are no tool-tips to indicate what it does, and there are other screw-heads in other places which do nothing, they’re just graphic elements. I’d seen some images of the surface triangles view, so I knew it was possible to display in this way, but it took me more than two weeks to discover, and then I found it by accident, trying to click on something else.

Two primitives shown in ‘triangle preview’ mode (click for larger image)

The majority of the modelling tools are on the right of the screen, though a few are at the top (I don’t know why they were separated). There is no conventional drop-down menu structure and right clicking with the mouse does nothing. All the menu icons are animated when you mouse over them, which is kind of funny the first couple of times and then useless after that. Clicking a button also causes a sound effect, which pretty quickly gets annoying, and because they can’t be turned off meant I worked with my speakers muted most of the time. Quite obviously the user interface, with its cartoony graphics, has been designed with children in mind, but in my opinion it’s entirely unsuccessful – it sacrifices ease of use and learnability for a few gimmicks. I also found it extremely patronising in its belief that somehow children will fall for a ‘wacky’ interface and ignore the limitations which some of the tools introduce.

Saved models are stored in ‘glass bottles’ at the bottom of the screen, any of these can be opened and worked on. And here Cosmic Blobs introduces what is undoubtedly the stupidest UI decision I have ever experienced – all models are auto-saved under their original name after each modelling operation. This means if you open a model, work on it, then decide you’re not happy with what you’ve done, you have to undo all the steps to get back to where you’ve started. If you open another model or quit the software, the original is lost and the version with the unwanted changes is saved. Tom Meeks advises copying every model before you open one, which works. But why a decision a was made to break with a convention which every other piece of software under the sun adheres to (including software that children will have used) is beyond me.

A bird’s head, from one of Tom Meeks’ tutorials (click for larger image)

The basic modelling procedure is therefore to begin with a saved model, or a primitive, and then use the modelling tools on the right to distort the shape. The main tools available allow you to pull or  push an area, to flatten and to pinch. By using two sliders the level of detail can be controlled, which means for example the pull tool can either pull a fine, needle like protrusion or distort the whole shape. In the top right corner are three sketch tools (line, arc and freeform), these allow 2D shapes to be drawn which can then be used to shape the model. The simplicity of these tools and the way in which they can be tried and immediately understood are the real strength of Cosmic Blobs. It only takes a few minutes to start with a sphere and already be shaping it in a controlled manner. To that extent Cosmic Blobs certainly succeeds in being an easy-to-use modeller. But the way the rest of the system is implemented is so poor, and to my mind counter-intuitive, that the software becomes effectively useless for anything except the most basic operations.

A sphere, with a sketch of a 2D arc (click for larger image)

The arc is used to push the sphere, which adopts the sphere’s profile (click for larger image)

As I said somewhere in the SketchUp posts, what I’m trying to do in these exercises is push the software to its breaking point. So I’m perfectly prepared to accept that Cosmic Blobs was only intended to be a very rudimentary modeller, and I’m expecting it to do far too much. But even if that’s the case, the software still isn’t very good at achieving even that simple task. What’s even more annoying is that with a few tweaks, or a few revisions (if it had continued to be supported), Cosmic Blobs could have been a 3D modeller quite unlike anything else that’s available now. There’s too many examples to list all of them, but as one illustration: after using Cosmic Blobs intensively for about a month, and on-and-off for another 6 months, I still don’t understand how the mirror function works. It just seems to have a mind of its own, sometimes allowing an object to be translated or modified in a certain way, and sometimes not.

What Cosmic Blobs is really good at is presenting simple, quickly understandable ways of manipulating objects. What it’s really bad at is allowing any kind of detailed control over the forms. As a very simple example, when rotating a model (rather than rotating a view of a model) there’s no way to rotate it accurately, by 90 degrees for example; it all has to be done by eye. I think this is the fundamental failing of the software – in its quest to be simple and, I suppose, appealing to kids, it became too dumbed down. I seriously doubt there are any children capable of modelling using Cosmic Blobs who don’t understand what turning something 90 degrees means. But with this simple omission (and there are a lot of others) the software has decided that there’s no way any kind of meaningful accuracy can be achieved. This philosophy is apparent throughout the software, from the total lack of any indication of size or scale, down to the fact that the edges of surfaces are very ragged as soon as you zoom in to any degree.

This close-up shows the poor surface quality that can occur (click for larger image)

Despite all the apparent limitations, I was still trying to push Cosmic Blobs as far as possible, to see how close I could get to modelling a real product. It was clear I wasn’t actually going to be able to model a working mouse – there’s no way to import files for one thing, and even if I could have brought in the critical features file for the mouse, there are no boolean operations which would allow them to be integrated into a model. Nonetheless, I wanted to see what the software was capable of when used in a way it wasn’t really intended. So to do this, I decided to try modelling some ‘real’ products, in this case some Ron Arad chairs. In the same way that the design for the SketchUp mouse suggested itself through the limitations of the software, the Ron Arad chairs were chosen because they seemed like something that might be possible to model, albeit crudely. Which was a pretty fair assessment, in the end.

Victoria and Albert armchair © Ron Arad (click for larger image)

I tried a few different chairs, but this one example, the Victoria & Albert armchair, demonstrates Cosmic Blobs’ strengths and weaknesses well. I started with a cube and used the tools previously described, first to create the external profile, and then to hollow out the seat and back shape. To get to the shape shown below only took about 15 minutes. But from this I found it impossible to get very much closer to the actual shape I was aiming for.

Half the Victoria and Albert armchair, work-in-progress (click for larger image)

Because the shape of the tool cant be changed (it’s always circular), pulling a certain area of the chair (for example the arm) also affects other areas which I wanted to fix. It’s not possible to cut an area away, only to push or pull, so making fine adjustments is very difficult, and even where it can be achieved the quality of the edge of the surface is very poor. But the biggest obstacle by far is the inability to control the surfaces at the line of symmetry – there’s just no way to achieve tangency. An alternative way of modelling would have been to model the chair as a whole (rather than in one half) with symmetry turned on; this would have ensured the surfaces were continuous. But then there would have been no way to guarantee that features were centred at the line of symmetry (you can’t snap to a plane, or indeed any object), and so again the problem would be a lack of accuracy.

Victoria and Albert armchair, mirrored, which shows the innaccuracies at the chair’s centre-line (click for larger image)

Whilst part of me wanted to persevere and find out a way to solve these problems, in the end I gave up and decided that spending more time with the software was just a waste. I was never going to get to a stage where I’d be able to create even a crude working mouse, and so the effort of learning more about Cosmic Blobs seemed redundant. Which was a shame, and I have to admit to feeling disappointed that I couldn’t demonstrate its capabilities in the way that I had with SketchUp.

Ultimately, I suppose, the software just wasn’t developed with enough insight or imagination as to what it could have become, or what children might have wanted to do with it. But I still find it intriguing to think about what Cosmic Blobs might have evolved into if Dassault Systemes hadn’t killed it. And there are some clues that maybe there were plans in the pipeline: for example it’s possible to export models as .vrml files, which are one of the formats often accepted by 3D printing systems. Unfortunately there’s no way to control the scale of the model – the bird’s head shown above measured 2.6 metres in diameter when I opened an exported file in Solidworks – but maybe it was a future intention to expand Cosmic Blobs into the realm of physical manufacture? Despite my criticisms of the way the software has been implemented, I believe it could have been developed to become a genuinely useful 3D modeller. A system for controlling the size of the model, a mirror/symmetry function that actually worked and a way of accurately orienting the model would have solved a great number of my problems, together perhaps with a sub-divide function to increase the surface accuracy. If these were felt to be too complex, what about different levels of software for different age-groups? If Dassault Systemes had persisted with Cosmic Blobs (and understood it as a ‘real’ modeller, rather than a cartoon representation of one) I seriously think that a lot of novice users (children and adults alike) would be using it today instead of SketchUp. It certainly has capabilities way beyond SketchUp’s in terms of modelling organic shapes. But instead, Dassault Systemes’ free offering is 3DVia Shape, a Google SketchUp imitator with far fewer users.

The third post in this series describes how the final design of the mouse was modelled and some of the problems encountered. Before talking about these problems however, I should state that to a considerable extent they constitute an unfair criticism. I’m well aware that the task I’ve attempted in this exercise is one that SketchUp isn’t intended, designed or advertised as being able to do. Nonetheless, I think that by describing the software’s limitations, the magnitude of the task that would face a consumer-designer, using software tools such as SketchUp, is better appreciated. It also makes clearer what the specification and design of a software tool aimed at consumers should be.

The final task in the design stage of the exercise (detailed in the previous post) was to create accurate sketches based on the minimum volume models, which were used as underlays. These drawings were then scanned and imported into SketchUp to act as templates. It was at this point, right at the beginning of the modelling phase, that SketchUp’s limitations began to show, because there is no way to choose which plane to import images into, they all come into the ground (XY) plane. That means that if you have a number of elevations, e.g. front, side, top etc, most will need to be rotated into place. But the image is treated as an object, you can only pick a corner or edge, which means aligning what you’ve actually drawn (rather than the edge of what you scanned) in each elevation has to be done by eye. It’s not a big gripe, but it kind of sets the tone for what’s to come.

The basic profile of the mouse, constructed using imported sketches as a template (click for larger image)

In a previous post I talked about how the rationale behind this exercise was that an ‘expert amateur’ could reverse engineer an existing product and make it available for anyone else to copy or modify. The modification bit is what I’m particularly interested in, and to make this easier I proposed that this expert amateur could separate out the ‘critical features’ necessary to ensure that any new design would work. In this case the critical features referred to things like screw towers and snap features (to ensure the parts align and fit together), supports for the pcb and mouse scroll wheel (to make sure the electronics fit), pushers for the switches under the left and right buttons (to make sure the electronics work), etc. These critical feature parts had been modelled in Solidworks, and needed to be imported into SketchUp, however the only non-native import option included with the software is for .3ds files, which Solidworks cannot create. This meant searching for a Rubyscript file which provided a common import option (in this case as an .stl file), which was relatively easy to find, but once again highlights the extent to which Google relies on the expertise and goodwill of the SketchUp community.

Critical features imported into SketchUp as .stl files (click for larger image)

Although the .stl importer worked well, bringing the critical feature parts into SketchUp was a frustrating experience. Within Solidworks I had created an assembly, then exported as an .stl file; this file then contained a number of discrete, solid parts. But because the critical features included cutters (to trim material away) as well as actual features, some of the parts overlapped. When imported to SketchUp, the parts were no longer seen as solid but instead as surfaces, and because of the way SketchUp works any overlapping surfaces are immediately absorbed into each other. So importing in this way was completely useless. Instead I had to create a number of different .stl files, none of which could contain overlapping parts, import each one into SketchUp, and then orient and align by hand. In all it took almost a day to figure this out and do it, a task which should have taken only a few minutes.

Having imported the critical features, I could begin with the actual modelling. The external and visible surfaces were created relatively easily, in part because of the number of test models (21) that I’d made during the previous phase. But it was when the internal features and details came to be modelled that SketchUp’s limitations became most apparent. As I’ve already said, in some ways this is an unfair criticism. However in a ‘professional’ CAD system such as Solidworks or similar, there are numerous dedicated tools to aid the task of modelling a product’s internal details. Considering the new design was relatively simple (in terms of surface complexity) and contained no draft angles (not needed for an additive manufactured part), the design would probably have presented few problems. A simple ‘Shell’ operation (to create wall thicknesses), followed by ‘Combine’ or ‘Cut’ operations to integrate the critical features, and fillets to finish the edges, would probably have achieved 90% or so of what I was trying to do. Unfortunately SketchUp doesn’t have a ‘Shell’ command, nor indeed any boolean commands (unless you pay $495 for the Pro version), nor a fillet command, and so all these operations were carried out by intersecting and trimming surfaces.

Save point after 2 days work, with most of the external surfaces completed (click for larger image)

Not only was this incredibly laborious and time-consuming, it also presented numerous opportunities to make mistakes. And of course, the more laborious and boring it felt, the more mistakes I made. These mistakes were then further compounded by SketchUp (unlike a parametric modeller) having no ‘history tree’; this meant that when a mistake was spotted there was no clue as to when it had been made. The only solution was to go back through the previously saved versions of the model until I found one which didn’t contain the error. One of the diary entries (which maybe I’ll have to censor before I submit the thesis) shows my irritation when it describes “three fucking hours wasted”?. I suppose I learnt my lesson though – at one point I was saving a new version every 15 minutes or so.

The middle part of the mouse, which contains most of the features for locating the pcb (click for larger image)

This isn’t to say everything in SketchUp is bad though. For one thing, the ‘Paste In Place’ command is fantastic – copy a surface or part from one file and paste in place in another, and the surface or part will appear in exactly the spot you expect it. I’ve worked with CAD systems costing thousands of dollars that can’t handle that as well as SketchUp. And that certainly made things easier: on numerous occasions when I needed the original of a surface which had been trimmed and absorbed into the model, all I needed to do was go back to a previously saved version, copy the surface then paste in place in the latest model. I can forgive SketchUp for many things because of the way this is implemented.

Unfortunately though, things only got worse as I got nearer the end of the modelling. Despite the previously mentioned Rubyscript plug-in which was found to help with the issue of identifying where a part was unable to ‘knit’ to become solid, it was still a time-consuming task. This wasn’t helped by some really bad graphical clipping which sometimes occurred when zoomed in close – I did find a suggestion on the SketchUp forum which was to disable hardware acceleration under the OpenGL preference tab, but on my machine this option was greyed out (i.e. couldn’t be turned off).

The finished CAD model (click for larger image)

And, just when I thought I had everything sorted, SketchUp threw up one last problem. In order to manufacture a 3D part via additive manufacturing it’s first necessary to create a file of the correct format, usually .stl or .wrl. All the parts contained within that file have to be fully enclosed volumes (or more colloquially, “watertight”), with no overlapping, redundant or unstitched surfaces. My final design contained three parts, as in the original mouse design, all of which SketchUp identified as being ‘solid’. In its vanilla version, SketchUp has a number of export options as standard, one of which (.wrl) had the potential to be used directly, and another (.obj) which I thought could be taken into an intermediary program and then re-exported. However when I started experimenting with the options a number of problems became apparent, and so for this reason I had to search for another Rubyscript plugin which would allow the export of files in .stl format. I made files in all three formats and imported them into three CAD packages (Rhino, Solidworks and ProE) in order to check their integrity (I used three programs so that, in case of problems, I could work out whether the issue lay with the SketchUp exported file or the importing CAD program). The results are shown below:

As can be seen, only the .stl option, provided by the Rubyscript plug-in, gave an exported file which could actually be used. The plug-in gave no options for the size or quality of file (usually provided by specifying the number of triangles), but the file size was about what I would expect (about 2.5Mb for the three parts), and when opened in Solidworks it looked okay. There didn’t really seem to be much option but to go with what I had.

Keyshot renderings of the finished model (click for larger image). After importing the .stl files into Solidworks I added some fillets (which isn’t possible within SketchUp) to make the model appear more realistic, however the sharp edges and corners reinforce the impression that this is a rendering rather than a real product.

The .stl files were output to an Objet Connex500 machine, and built using the VeroWhitePlus material. The system allows the choice of a matte or gloss finish with this material and I chose gloss as it would tend to highlight mistakes rather than hide them. I received the parts about a week after they had been built, and one of the first things I noticed was that the top part had deformed, such that the two mouse buttons were not at the same height. This is apparently a well known property of the material if the part isn’t stored in the right position; I was advised to run the part under a hot tap to try to get it back into shape, but actually after leaving it on my desk in sunlight it returned to its normal shape. However, there was a more fundamental problem, which was essentially that the main body part was too small. Although the PCB fitted inside, it was very tight and took a considerable amount of time easing it into place. At one point I broke the interior feature designed to hold the mouse scroll wheel (though actually this was as much to do with clumsiness as with bad fit) and resorted to super glue to fix it. The snap features at the front of the mouse, which located the middle part (in blue in the renderings above) to the base were also over-engineered, making them too stiff and so even harder to get the parts to fit together. If this was project was simply for my own use I would probably have started sanding things down with some wet-or-dry paper and made the parts fit better that way, but as part of the PhD I need to be able to show them in their raw, unadulterated state. There was some good news though; was once assembled, the buttons worked, locating correctly on the tactile switches on the PCB, as did the scroll wheel.

Parts from the Objet Connex500 machine (click for larger image). The snap fits were so stiff that once assembled the middle and bottom parts couldn’t be taken apart again.

The assembled mouse, with pcb inside (click for larger image)

And so the final part of the exercise was to return to SketchUp and modify the model one last time. This involved widening the whole product by 1mm, though of course it wasn’t just a matter of scaling things, instead I needed to move certain features but not others. As I expected this wasn’t a simple task, and it took more than a day to achieve. I also reduced the size of the snap locators so they were more flexible. Having made the changes and created new .stl files, this time I uploaded to the Shapeways site and used that service, in order to get better quality parts. I’d hoped to get the middle part polished, but this wasn’t available in the time I needed to receive the parts back, so instead I opted for SLS ‘White, Strong & Flexible’ nylon for the base and button parts, and SLS ‘Frosted Ultra Detail’ acrylic for the middle part. After waiting for a couple of weeks to get the parts back, to my relief they fitted together fine and I was finally able to assemble a working mouse. In all it took about ten weeks from first sitting down to learn SketchUp to ‘proving’ it’s possible to use SketchUp to create a unique, complex, functioning consumer product.

Parts supplied by Shapeways (click for larger image). Even though the snaps had been made smaller, the parts still couldn’t be disassembled once put together.

Scroll wheel and pcb fitted (click for larger image)

The final assembled product (click for larger image)

Throughout this series of posts I’ve referred to a number of CAD models and files which were created. These are all available, in different locations, to download and are subject to the same Creative Commons licence as the rest of this site (ie an Attribution-Share Alike licence).

The SketchUp model is available from my page in the Google 3D Warehouse

The models I used for manufacturing the parts are available from my page at Shapeways

The .stl files, which can be used for manufacturing the parts, can be are available from the download page on this site (as are the SketchUp files).

The Critical Features file, which can be used as a start point to design a functioning mouse, is also available from the download page in both .stl and .step formats.

The Safe Model is also available from the download page. Use this to ensure any new design is big enough to accommodate the internal parts of the mouse.

The Solidworks file of the reverse engineered mouse isn’t available for download – it’s 168Mb, which is way over the limit my site allows. If anyone wants a copy send me a mail and I can give access to my ftp site.

The second part of this series of posts describes the process of designing a new mouse to be modelled in SketchUp. Although I’m dividing the exercise of learning, designing and modelling into three posts, the reality was that the three were intricately intertwined. Learning SketchUp was an ongoing process right up to the end of the exercise, when trials had to be made to determine the best method of exporting the model to the Objet Connex500 machine which was used to produce the part. The limitations of the software also had a profound effect on the actual design concept, which changed and developed as I started to understand the capabilities of SketchUp better. For a significant part of the design phase there was also a continuous back-and-forth ‘conversation’ between my paper-based sketch designs and the computer-based CAD model designs, as concepts were tested to determine whether their modelling within SketchUp was actually possible.

Before I start, I should say something about the way in which the design phase was conducted. Because this research forms part of my PhD, the design work that I do will be looked at and interrogated in a way that’s very different to the way it’s used in my professional work. I very rarely allow clients to see my ‘raw’ sketches for example, and where I do they will have been edited and put into a ‘logical’ presentation. As a rule clients aren’t particularly bothered about all the experiments and dead-ends that form part of the design process; they want to know about proposal and the thinking behind it. In an academic research context though, the requirements of what’s generally known as practice based research are different. One of the hardest things I’ve had to come to terms with during this stage of the PhD is that, central to the viability of practice-based design research as a methodology, is the understanding that a PhD is granted on the basis of the quality of research, rather than the quality of design. That’s not to say that any design work undertaken can be of sub-standard quality, but rather that it has to be planned, undertaken, documented and analysed with the same degree of rigour employed by more conventional methodologies. This conscientiousness is probably the fundamental difference between practice-based design research and the practice of design itself, where intuition, tacit knowledge and undocumented approaches are common, not to mention the use of primarily visual, rather than written, forms of communication.

One of the first test models (click for larger image)

In the past there has been a lot of debate, some of which is still ongoing, regarding the validity of practice-based design research and whether it contains sufficient rigour. I’m not going to go into it here, suffice it to say that this particular part of my methodology will form a significant portion of my thesis. I’ve included a few references at the end of this post for anyone that’s interested. My own particular method of recording and reflecting on my design work was to keep a diary which was filled in at the end of each day, this is a technique described in detail by Owain Pedgley¹, a predecessor of mine at Loughborough. The reasoning for this approach is that a diary offers the best compromise between the conflicting requirements of immediacy (to ensure relevant information isn’t forgotten) and non-interference (to avoid interruption or distraction which would hinder the work being undertaken). A diary isn’t perfect of course – the importance placed on a certain activity or decision is naturally prejudiced, and there’s always the temptation of editing to make yourself appear more competent or talented. And I suppose that’s another fundamental difference between research and practice – the need to be honest and show yourself and your work in its true light, rather than the polished eye candy that designers often try and present as evidence of their process.

An early page from the design sketches (click for larger image)

The test model from that page of sketches (click for larger image)

Usually I work on A3 paper when sketching, but for this exercise sketching was carried out on A4 – this allowed the sketches to be easily scanned and also meant they’ll fit (physically) into an appendix. I used images of a minimum volume ‘safe model’ as underlays to make sure any sketches were realistic in terms of size. Because I was relatively unfamiliar with the software, a lot of the design phase entailed ‘testing’ the sketches to see if they could actually be modelled in SketchUp. This is quite different to the way I’d usually work, where I deliberately try to be ‘ignorant’ as far as the capabilities of the CAD software are concerned. If I’m not able to recreate a concept exactly in CAD, I’ll change the concept at that stage, rather than limit myself earlier on. But in this case I knew that I was constrained by the software’s limited toolset, and I wanted to be sure that the product I designed was realistically able to be modelled. A number of concepts which, on paper, had appeared promising were discarded because of their unsuitability for modelling in SketchUp. And so the limitations of the software became an integral feature of the decision making process regarding which concepts to reject and which to pursue.

Two ideas which didn’t go much further… (click for larger image)

A very early, and fundamental, decision was to create a concept which played to the strengths of SketchUp, rather than attempt to force the software to create forms it was ill-suited to model. The lack of ‘loft’ or ‘blend’ tools in SketchUp meant that the construction of complex surfaces – a fairly mundane task within most modern CAD software – was extremely problematic. However the ability to ‘pull’ one surface out from another meant it was easy to very quickly build a multi-faceted model. This capability suggested a design made up of deliberately planar surfaces with hard, non-tangential intersections. After working on a few ideas that suggested themselves early on, I made an image search and built up a couple of mood-boards for inspiration.

Mood boards (click for larger image)

Reviewing the design sheets with hindsight, the earlier sketches show a preoccupation with caricaturing the mood-board images, rather than allowing the new concept to find its own aesthetic. But this inhibition recedes as the sketches develop and a confidence in the design direction emerges. The first sheets show little consideration of functionality, but instead concentrate on an exploration of sculptural form; my intention at this point was to identify a number of directions to explore within one over-arching theme, and to introduce constraints of functionality, ergonomics, production etc as the concepts developed. This doesn’t particularly conform to a text-book approach to design, but in a situation where the product’s functionality was so rigidly predetermined (by using the original product’s pcb), it seemed to be a reasonable approach.

One of the first sheets to show what would become the final design (click for larger image)

A test model as the concept develops (the top surfaces are now curved), I was also experimenting with ‘shelling’ out the interior (click for larger image)

As the concepting phase progressed, and particularly as a number of concepts were rejected due to the limitations of SketchUp’s modelling capabilities, a ‘final’ design began to emerge. In truth, one of the main drivers behind deciding on this concept was a desire to push SketchUp to its limits, because I felt this was the best way to really understand where its strengths and weaknesses lie. I also wanted something which stood out as being different to common computer mouse designs, something which advertised through its aesthetic that there weren’t just the normal considerations behind the design.

One of the last sketch sheets to be made, close to the final design (click for larger image)

And one of the last test models (click for larger image)

In all this phase of the exercise took five days, which meant that including the time spent learning SketchUp I’d taken nine days to get to a design I wanted to take forwards. Although this felt pretty quick, one vague guideline I was trying to follow was that it should take around a month to get to the final design – if it took a lot longer than that it kind of implies that the software actually isn’t that ‘simple’ to use after all. In fact the final stage of the exercise, that of making the detailed, production-ready model, took another 15 days, and this alone demonstrates where the biggest difficulties lie in using SketchUp to create a ‘real’ product. But I’ll come onto that in the next post…

¹Pedgley, O (2007), ‘Capturing and analysing own design activity’ in Design Studies, 28(5), pp. 463-483

And a few more references regarding practice-based research:

Arts and Humanities Research Council (AHRC), (2007), Practice-Led Research in Art, Design and Architecture, [online, pdf download], available from: http://www.archive.org/download/ReviewOfPractice-ledResearchInArtDesignArchitecture/Pactice-ledReviewNov07.pdf

Binder, T. and Redström, J. (2006), Exemplary Design Research,  in Proceedings of the DRS International Conference 2006, 1-4 November, Lisbon

Durling, D. (2002) “Discourses on research and the PhD in Design”, in Quality Assurance in Education, 10(2), pp. 79-85

Friedman, K. (2010), When the Practice-Led PhD is different to the PhD by Thesis, JISCMAIL PhD-Design Archives [online], available from: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=PHD-DESIGN;575d58dd.1011

Yee, J. (2009), ‘Capturing tacit knowledge: documenting and understanding recent methodological innovation used in Design Doctorates in order to inform Postgraduate training provision’ in Proceedings of EKSIG (Design Research Society Special Interest Group on Experiential Knowledge)  2009, 19th June, London

As I said at the beginning of the series of posts on D.I.Y. Reverse Engineering, this part of my research is looking at how feasible it is for a consumer, using currently available technology and software, to design and manufacture their own products. Reverse engineering an existing product is necessary to provide the foundation for this design and manufacture to happen, but what’s more important is looking at the opportunities and obstacles consumers currently face. And so the next few posts will talk about the issues involved in designing and manufacturing a custom-designed mouse, using Google’s free SketchUp modelling software.

The ways in which the design and digital manufacture of products by consumers could revolutionise traditional manufacturing has been widely predicted, Marshall Burns and James Howison for example, predicted the “Napsterization of manufacturing”¹ in 2001, and Evan Malone and Hod Lipson (developers of the Fab@Home system) have described additive manufacturing as having “the potential to transform human civilization.”² However, whilst the hardware and services which might enable consumer fabbing have been in development for some time, the processes by which consumers might conceive and design ‘fabbable’ products have tended to be assumed or glossed over. Neil Gershenfeld for example, writing in Fab about how a novice might use modelling clay to prototype a design, describes a process in which the clay shapes would be 3D scanned and imported to a CAD software environment:

“they can then be manipulated like any other object: scaled larger and smaller, bent around a surface, or merged with other components by Boolean operations. The resulting model can then be output on a fabrication tool such as a 3D printer or an NC mill, effectively converting the clay into plastic or steel, with enhancements added through the CAD editing.” (pp.130-131)

But such a description, whilst attractive in its simplicity, ignores the realities that the process would entail using current technologies. The use of a 3D scanner is a skilled operation, as is the importing of the data into a 3D CAD system and its subsequent analysis. The data, having been imported, would probably generate a model which required repair and refinement, which in turn assumes in-depth knowledge of a high-end CAD package, as does the CAD editing which Gershenfeld refers to. Even if a consumer had access to the expensive tools which the above passage implies, it is unlikely they would have the time (likely measured in years) or inclination to become adept at their use. And even if they did have both the tools and the skills, Gershenfeld’s scenario still relies on the consumer being able to create a decent clay model in the first place. Well, I’ve done a fair bit of clay modelling, and it definitely isn’t easy; indeed the images that Gershenfeld shows suggest most people’s clay modelling skills aren’t much better than you’d find at nursery school.

So what I’m trying to do is establish whether it’s possible for a skilled, but non-professional, consumer-designer to conceive and manufacture a unique design for a relatively complex electronic product, using only readily available and easily mastered tools. The full course of the research will involve looking at a number of different software packages, but this post concentrates on SketchUp, which is the first modeller I’ve tested. The criteria I used to judge whether a particular modelling package was appropriate were basically

1. Cost. The software should retail for less than $100 to satisfy the requirement of being ‘readily available’
2. Ease of Use. The software should make claims to being easy to use or consumer-friendly

The SketchUp interface, showing the basic toolset along with the BezierSpline plugin toolset, © Google (click for larger image)

Clearly the cost issue is a little contentious – most people know that pretty much any software can be downloaded for free from certain torrent sites, and I know from first hand experience that you can buy a fully unlocked, working copy of Catia for less than $20 in China. But if I’d allowed that argument it would have meant every CAD package was open to consideration, and at the same time I wouldn’t have been researching anything new (obviously, everyone knows professional CAD systems can be used to produce manufacturable models). So the requirement that the software should claim to be easy to use was important, and this is what also ruled out Blender, for instance. SketchUp satisfies both requirements: the basic version is free to download and use, and Google make much of SketchUp’s ‘simplicity’

“To build models in SketchUp, you draw edges and faces using a few simple tools that you can learn in a small amount of time. It’s as simple as that.”

What’s more, I knew that SketchUp had a number of limitations with regard to its toolset, this would therefore make the exercise valuable in understanding the challenges faced when using ‘simple’ software. Clearly, the more capabilities a developer removes in the quest for simplicity, the more restricted the user is in what they’re able to build. It’s a balancing act, and one that had significant consequences in the design of the new mouse.

In some respects the simple test of SketchUp’s suitability as a consumer modelling package would be whether it was possible to create a model which could be output via an additive manufacturing process. However in order to better understand and assess the suitability of SketchUp for this task, a number of criteria were drawn up against which its performance could be measured. These were the things I was paying particular attention to as I started to learn and use the software, and will later be used to judge the other modelling packages I’ll be testing.

Quality of User Experience

Cost
Platform (PC / Mac / Unix / Other)
Ease of Installation
Documentation
Tutorials
Bugs
Support (Company)
Support (Community)

Ease of Use

UI Structure (icons, menus, hidden items etc)
Presentation (shaded or wireframe, single view or multi view etc)
Follows existing paradigms (is similar to other software)
Ease of View (zoom, rotate etc)
Repetition of function (different tools achieve the same result)
Redundancy (tools are not used)
Creates modifiable models

Communication with External Environment

Tools required (mouse, tablet etc)
Inputs existing file formats
Outputs existing file formats
Outputs RM data formats

Download and installation was simple and followed the usual automated process. Although there are both PC and Apple versions of SketchUp, I installed on the Windows partition of my MacBook Pro because some of the other software I’ll be testing is only available for the PC; installing on different platforms might introduce problems when making comparisons.

The SketchUp installation includes no manual though an online reference guide exists. Tutorials were also provided online as YouTube videos, but these are primarily ‘watch and learn’ rather than directed lessons, which means they tend to act as encouragement to simply experiment with the tools. As with a lot of software, the initial tutorials are fairly limited, covering only the basics of usage. In the past I’ve found that a good way to learn more sophisticated techniques can be to study models made by more expert users – this is particualrly the case with parametric CAD software, where you can move back through the history of the model. This can be really valuable in understanding not only the individual methods used but also the strategy employed. SketchUp provides an extensive library of models which can be freely downloaded from the Google 3D Warehouse, but unfortunately most of the best models haven’t actually been modelled in SketchUp, but rather exported from another CAD program. This causes a lot of confusion amongst users (see the comments for this model, for example), and it also gives little indication of SketchUp’s true capabilities.

From a tutorial showing how to model a car. The lines indicate non-tangent surface edges.

The lines can be removed (ctrl-erase), but this is purely visual, the edges remain non-tangent.

There are also a number of user-created tutorials, but almost all the ones I tested were of poor quality – either hard to understand, or simply resulting in a poor model like the one above. To try and overcome these limitations I decided to download an appropriate model which had been created in SketchUp – in this case a digital camera – and attempt to recreate it. It’s not a direct copy, I changed some things just to see if I could, and added a few details, but in this way I was ‘forced’ to try and understand how the software worked. My model can be downloaded here. Recreating the camera took approximately two days, which, combined with the official video tutorials, added up to approximately four days ‘training’. After that I felt proficient enough to begin the design phase of the exercise, which I suppose is testament itself to SketchUp’s ease of use, although it would be a mistake to assume I knew how to use it well. To be honest I was still learning some of the nuances as I exported the finished CAD file to the 3D printer.

Nikon digital camera, modelled only in SketchUp (click for larger image)

SketchUp was acquired by Google via a buyout of its original developer (Last Software) and the first version was released in January 2007. It was originally intended primarily as a tool for modelling buildings which could be placed into Google Earth, and the software continues to display its heritage by the concentration (of its tools and tutorials) on architectural modelling. As long as you’re not trying to model organic shapes, SketchUp’s tools strike a good balance between functionality and ease of use. The problems come with trying to model anything more complex than an extruded spline. SketchUp’s approach to the creation of 3D objects is certainly simple. A 2D shape is drawn on a plane, when this shape is closed (i.e. the lines defining it contain no gaps) a face is formed, which can be extruded, moved or swept along another line or edge. Shapes can be drawn on the faces of objects to add or subtract from the original. In this way it’s pretty easy to pick up the concept of making 3D objects.

To create a feature, a shape is sketched on a face or plane.

The new face can then be extruded using the Push/Pull tool.

Freeform shapes can also be sketched, and Push/Pull can be used to cut into an object.

But there are some tools which are conspicuously missing, tools that most designers would consider fundamental. In particular there’s no way to create lofts (a surface between two non-identical curves or edges), no way to create patches or blends between surfaces, and no way to create fillets. This last one I found particularly bemusing – 3D CAD software has been able to add fillets to edges almost since it was first invented, how difficult would it be add this capability to SketchUp? This is something which seriously limits SketchUp’s ability to appeal to designers – fillets are so fundamental to products that when you design something without them, the results look crude and amateurish. Even in a rendering, the model immediately looks ‘wrong’.

It is possible to fillet edges, but it’s a 7-step process and doesn’t always work.

This lack of a fillet command frustrated me so much that in the end I actually worked out a way to create them. It basically involves creating a sweep using the SketchUp ‘Follow Me’ command. But it’s tedious and difficult to set up, doesn’t always work first time, and only gives predictable results on planar edges. I made a tutorial to demonstrate which can be downloaded here, but it’s probably significant that when I came to design the new mouse, I deliberately went with an aesthetic that avoided the need for filleting. It looks crap in renderings though.

Modelling the camera also highlighted another very important aspect of SketchUp – its user-developed tools. On a number of occasions the software reported that the model wasn’t ‘solid,’ an essential requirement if it was going to be manufactured via an additive manufacturing process. However, within SketchUp, there is no way to discover what is actually causing such problems, which by their nature tend to be hard to find (the easy-to-find ones have usually been spotted and fixed). But a solution was found within a resource library provided by Google which contains Ruby scripts – plugins for SketchUp which have been developed by users. These plugins are unsupported by Google, who provide no guarantee as to their quality, nonetheless a significant number of such plugins are well written (many have been updated numerous times) and extend SketchUp’s capabilities dramatically. I managed to find one plugin (Solid Inspector) which analysed a model and showed any problems preventing it from becoming solid; it doesn’t work perfectly, but without it I definitely wouldn’t have been able to complete the new mouse design. A couple of others which I used were this one for drawing splines, this one for importing .stl files and this one for exporting them.

Most of the tools inside SketchUp are easy to use and seem to work exactly as they should, this results in a product which is incredibly easy to pick up and start working with. But inevitably in the quest for simplicity, some functionality has been left out. As well as the missing tools already mentioned, there a few others which I think could have been added without making things too complicated, for instance there is no measurement tool – to get the length of a particular edge for example, you need to add a dimension, which then needs to be deleted again. But without doubt the biggest frustrations for me came from two elements which seem to be particularly badly implemented.

A circle in Sketchup is actually made from 24 straight edges.

The first is the way that SketchUp produces arcs and circles, and it stems from the fact that all arcs are actually constructed as a series of straight lines. This is a problem in itself for anyone who wants to create physical objects rather than just images, because it means that surfaces are never truly smooth. However the problem is compounded by the fact that the default number of segments is 12 (24 for a closed circle), which gives a very faceted circle, or cylinder if the circle is extruded. The number of segments can be increased manually, but the default of 12 can’t be changed, and once you’ve exited the arc construction tool, what you’ve drawn can’t be changed either. Especially early on, I lost count of the number of times I forgot to increase the number of segments and only realised further down the line, at which point I had to decide whether to delete out the feature I’d been working on and remodel it, or just carry on. Just allowing the default number of segments to be changed in the preferences would drastically improve the tool.

The second frustration came from the way SketchUp implements layers. Unlike every other piece of software I’ve used I think, elements that are placed on different layers within SketchUp will still interact with each other, even if their layers are hidden. So a feature you’ve been working on and then hidden on one layer will merge with another feature on another layer, even if you want to keep them separate. It just doesn’t seem to make any sense – if I wanted them to merge why would I put them on different layers? You can get round it to some extent by grouping sets of surfaces (groups can’t interact with each other), except that it’s possible for a group to be on one layer, while the surfaces contained in that group are on others. The behaviour is also particularly badly documented, I couldn’t find anywhere that explained the way that groups and layers work, and it took me about two weeks of thinking there was a serious bug before I worked out what the ‘logic’ was (to fix things you first have to move the group so it won’t interact with anything else when exploded, then ‘explode’ the group into its constituent parts. Deselect and reselect all the parts, place them on a layer, then recombine them as a group again).

Frustrations aside, SketchUp is a great tool. For sure, it is basic: anyone with previous experience of CAD software will find the capabilities of SketchUp extremely limiting. But as the next few posts will show, it’s nevertheless possible to model a manufacturable consumer electronics product using the software, and at the same time introduce, by necessity, an aesthetic which might not otherwise suggest itself. For anyone with no previous experience or access to CAD software, this could be a liberating opportunity. The problem, I suppose, is that opportunity isn’t the same as reality. SketchUp, and similar consumer CAD packages, put modelling tools in the hands of those who wouldn’t otherwise have access to them. But there are still a lot of issues that might prevent someone actually manufacturing a product.

¹ Burns, M. and Howison, J. (2001) ‘Digital manufacturing – Napster fabbing: Internet delivery of physical products’ in Rapid Prototyping Journal, 7(4), pp.194-196

² Malone, E. and Lipson, H. (2007) ‘The Factory in your Kitchen’ in Proceedings of the MCPC 2007 World Conference on Mass Customization & Personalization, 7-9 October, Massachusets Institute of Technology (MIT)

The third post in this series looks at what is an inevitable feature of any product development process – the checking, correction and modification that occurs when the first prototypes are available. Even though I had reverse engineered an existing (i.e. previously ‘proven’) product this was still a stage I was expecting to have to go through; the inaccuracies in measuring together with the new tolerances introduced by the selective laser sintering (SLS) process meant it was highly unlikely that everything would fit first time. Even so, it was still a surprise to see how much my model differed from the original product.

Having created the Solidworks CAD model as described in the previous post, an .stl file was exported for each part so that SLS prototypes could be made. In common with most CAD software Solidworks allows you to tune the accuracy of the .stl file by adjusting the linear and angular tolerances. Playing around with these options resulted in some large variations in file size:

If my aim in this research had been to create the most accurate file possible I would clearly have gone with the fourth option. However, in keeping with the original scenario what I’m aiming for is ‘good enough’, within the constraints I’m operating to. For that reason I went with the third option, reasoning that more people are likely to download the file if it’s significantly smaller. But I can also see that’s not a completely water-tight argument – it could also be reasoned that anyone likely to engage in this activity will probably have a fast broadband connection and not be too worried about the size of the file. This might be something I have to reconsider later in the research, although it would also be necessary to manufacture both files and see what the differences in quality actually are.

SLS parts of the mouse (click for larger image)

SLS base of the mouse, with the original pcb and laser light guide fitted (click for larger image)

The SLS parts were produced by Rapid 3D, a prototyping agency in the UK that I have used previously. Although not particularly clear from the above image, the three parts were all manufactured in different orientations (to optimise the surface quality); this was something determined by the agency. This orientation of what might otherwise be identical parts is a major reason for differences in mechanical performance in rapid prototyped / rapid manufactured parts, because the layer-by-layer build-up of material introduces a ‘grain’. In this instance it’s the surface quality which is most important for me, but in a situation where a certain mechanical property was critical, it would be necessary to pay careful attention to the way in which the ‘grain’ of the part lays.

The most obvious thing about the parts when I received them was that they didn’t fit together. And so a process of analysis and measuring began. First of all, I needed to know if problems were down to the model or the process, in other words how closely did the dimensions of the SLS parts match those of the CAD file. In a proper engineering process certain functional dimensions would have been determined in the design of the part ,and the checking of these against the real part would be an important part of a quality assurance program. Of course, in my haphazard way of proceeding I hadn’t done any of that (another lesson for next time), and so my checks basically involved looking at where the parts didn’t go together and then trying to determine why.

Basically what I found were four classes of error. The first I’ll simply call ‘mistakes’, and I’m happy to say I only found one of these. Along the inside of the bottom part there is a channel which the mouse cable sits in, which guides the cable under the pcb, around the back and into a connector. On the real part the width of this channel is 4.5mm, but I had modelled it as 3.5mm, which meant the cable did not fit. I’ve absolutely no idea how this happened, so I’ll just put it down to ‘one of those things’.

Measurement of the channel to guide the cable (click for larger image)

The second class of error is one of fit, where the mistake is in the original model. Again I only found one of these, though it was in a fairly important area, where the moveable surfaces which form the buttons click-fit onto the main body. I suppose this could be classed as a mistake, because it resulted from me not understanding exactly why the original part had been designed in the way that it had. But at the same time I deliberately changed the design, so it’s not the same kind of mistake as the first. Anyway, the result was that although the buttons did click into place (just), they then didn’t move. To rectify I made the holes slightly bigger and changed the design to more closely resemble the original part.

Original design for the mouse button pushers

Revised design for the mouse button pushers

The third type of error is also one of fit, but this time due to tolerancing rather than mistakes in the original CAD file. In general I had worked to a tolerance of 0.2mm where no friction fit was required. In specific areas this was often okay (though a bit tighter than ideal), but over the whole product it proved too demanding. For example, the top button cover fits to the main body by the click-fit buttons I just talked about, and by a screw tower at the back of the mouse. The screw tower of the button cover fitted the hole of the main body, and the snaps of the button cover also fitted their associated holes, but both were so tight that the cover couldn’t be made to fit in both places simultaneously. For this reason the general tolerance was changed to 0.4mm.

Measurement of screw tower (click for larger image)

Finally, by far the biggest source of error was something I have already mentioned a number of times: the inaccuracy of the images I was using to trace over. Whilst I’d managed to catch a lot of these, it was probably inevitable that a number would creep through to the final model. One of the biggest was in the distance between the guides which hold the scroll wheel and the switch on the pcb which is operated when the scroll wheel is pressed. On my modelled part the distance between these (shown in the image below) was 20.8mm, but in the actual product that dimension is 19.85mm. Whilst the switch just about operates, this 1.05mm discrepancy makes the tactile quality of the click very inferior. Knowing what I know now, I can’t stress how much effort it would have saved if I’d re-shot those photos when I had the chance.

Measurement of scroll wheel guide and switch (click for larger image)

Having measured, checked and modified the model, the obvious next step was to get new SLS parts made, which is what I am having done right now. Of course I am very much hoping that this time everything will fit. In some ways I am reasonably confident, perhaps because even with these early parts the pcb fitted into the main body quite well, with the scroll wheel sitting nicely in its guides. But my original intention was that the metric for deciding whether this exercise is a success would be whether any one of the original parts could be swapped for any one of my modelled parts. I’m now wondering if that’s going to be too ambitious. Maybe the best I will achieve is a working product, but one where the parts aren’t interchangeable with the original. At least at this first attempt.

This post deals with some of the practicalities of DIY reverse engineering. I’ll go through the way the mouse was measured and modelled, talk about some of the tricks and pitfalls, and the things I’d do differently next time. As I mentioned in the previous post, the scenario I’m working to is that of someone reasonably skilled at CAD modelling but without access to expensive 3D scanning equipment. That person models the mouse and makes the files available for download by others. To simulate this I’ve only used commonly available tools for measuring. To make the CAD model I’ve used Solidworks, which I admit isn’t the most readily available bit of CAD software, but my argument would be that anyone committed enough to reverse engineer a product in this way will be able to get their hands on a copy, one way or another. My own copy is legit, just in case you were wondering.

Measuring the Mouse

Tools for disassembling and measuring

In no particular order, the tools I used for disassembling and measuring the mouse were as follows:

Ruler: actually not used that much, because it’s not accurate enough. But okay for checking measurements quickly.
Vernier Calipers: the most used item. These are analogue so not quite as easy to use as digital, but they’re cheaper, and just as accurate once you know how to use them.
Torx Screwdrivers: in truth these weren’t needed for the mouse, which has been assembled using pozidrive screws. That was a bit of a surprise, and I’d expect that anyone reverse engineering consumer electronics products would find themselves needing these pretty quickly.
Scalpel: for cutting through and removing adhesive labels
Mini Screwdriver set: for unscrewing small screws, as if you couldn’t guess
Anti-Static bag: once I’d removed the pcb I kept it in here. To be honest I’m not sure how necessary this is – I’ve never destroyed a pcb just by handling it. But it’s a cheap enough precaution if you want the product to work when you rebuild it.
Earthing strap (not shown in the picture): again a cheap precaution, wear it around the wrist and attach to a radiator pipe.

These tools are enough to start taking some accurate measurements, but they’re a long way off being able to provide all the measurements needed to recreate the mouse in CAD. One of the reasons for choosing a mouse, and this one in particular, for the exercise was that the split lines between different parts follow some quite complex curves (by that I mean curves which are splines rather than arcs, and which lie on more than one plane). These curves are impossible to measure using conventional equipment, so instead they were photographed, and the images taken into Solidworks so the curves could be traced. To take the photos I used a Nikon D40X SLR mounted on a tripod, with a 28mm lens (at the time I didn’t really appreciate the affects of distortion. Big mistake, as I’ll talk about later). I also experimented with a flat bed scanner but this was only effective on the flat base of the mouse.

Side view of the mouse

Side view of the mouse, with curve sketched in Solidworks

The 3D profile of the curve (click for larger image)

Even before I began it became apparent that the photos I’d taken weren’t as accurate as I thought. Since there was no way of shooting all the photos (of top, front, side, rear etc) from a fixed distance, I knew I would have to resize them some in Photoshop. But when I started to overlay the images in Photoshop it was clear there was a degree of distortion in some of the images, so that they didn’t line up correctly, even when re-sized. If I was doing the same exercise again I would have re-shot the photos using a 50mm lens (I’m not exactly sure how much this would have improved things, but from what I’ve read it would have helped), but instead I manipulated some of the views using the Warp command. This was a mistake that would have ongoing implications further down the line…

Modelling the Mouse

Rather than take a whole series of measurements and then start modelling, the workflow was more along the lines of ‘start modelling, then measure where required’. I followed what – for me  - is a fairly standard modelling process, working purely in surfaces, on one half of the model, to begin with to get the overall shape, then mirroring and knitting to get a basic solid, and then splitting the solid and using solids or surfaces as appropriate on the individual parts. In this case the mouse was made up of three parts as the exploded view of the finished model shows.

Exploded view of the Solidworks model (click for larger image)

As I began modelling one thing I realised I had to do was decide how closely I wanted to replicate the original parts. For example the side view of the mouse shows a very distinct witness line created by the shut-off of the injection mould tool. This is something that most designers would normally try to avoid – I certainly wouldn’t be happy handing off a part like this to a client – and replicating a visually ugly artefact of a process I’m not using is clearly a folly: since additive manufacturing doesn’t use tooling there’s no requirement for draft. On the other hand as the line runs around the back of the mouse it’s obviously been detailed as a strong feature, which defines the smoothly sloping upper surface from the curving underside. Removing the draft altogether would lose this feature in a bland blend. In the end I kept the hard edge all along the bottom to the point where (on the original part) it angles upwards, but instead of replicate this angle I made the line run around the front. This was probably the most noticeable difference between my model and the original, but the new parts contain numerous, smaller details where similar decisions were made.

Witness line on the original mouse body

Modified line on the modelled mouse body

It was at the point where I began detailing the structural elements of the mouse – ribs, snaps, screw towers etc – that the weakness of relying on the photo images really became apparent, and so the necessity of measuring the original parts increased. Even though I had shot the images at the camera’s highest resolution (10 megapixels), when zoomed in the graininess of the image meant any measurements were only accurate to about 0.4mm, whereas I was working to a tolerance between parts of 0.2mm. What’s more the part with the most features, the base  of the mouse, is moulded in a translucent plastic, which makes reading the photographic image even harder as it’s not always clear which edges are which. For these reasons I relied mainly on the vernier calipers at this stage, and it was here I really began to appreciate the problems which the distortions of the camera’s lens had introduced. As I measured features and their positions, and began adding them to the CAD model, it became obvious that they just didn’t align with the their positions on the photographic images. The worst discrepancy I identified was 3.1mm, and if I tried to fudge things a bit in one orientation it just made things worse in another. And so there was no option but to accept that I couldn’t rely on the images, and to go purely by my measurements. Not only was this a lot more time consuming, it meant I needed to go back through the whole model and try to find the obvious errors.

Of course, for reasons I discussed above it’s impossible to work purely by measurements on the curved surfaces of a product such as this mouse. So I was forced to rely  on tracing contours from photographs, even though I knew the photos weren’t accurate representations of the product I was modelling. At this stage the best thing I could have done, in terms of creating an accurate model, would have been to re-photograph the product and start again. But that would have meant discarding almost a month’s work, which was something I couldn’t face. In this instance I decided to continue and hope I could catch any errors after the first round of prototypes, but it’s something I’ll be very wary of in future.

One of the advantages of working in a CAD package like Solidworks is that it’s very easy to catch errors in assembly. I tend to work inside single multi-body parts, which I think makes these kinds of errors less likely because you can easily see all the parts of your product without switching into and out of Assembly mode. But errors still happen, and so tools to check interference and clearance can save a lot hassle. Here’s one that I caught, where a boss from the button cover locates on a flat surface of the main body.

Solidworks’ interference check interface (click for larger image)

And finally, here’s the finished model. The next stage was to output in .stl format and make some physical parts, which I’ll cover in the next post.

The finished model, rendered in Keyshot

X-Section through the finished model (click for larger image)

The next few posts deal with a project which is making up a significant part of my PhD research, which is to reverse engineer a product, in this case a Microsoft branded mouse, and then to design and fit custom parts to it. I’ll start by explaining why I’m doing it, then go through the process of reverse engineering a product using only some basic tools, and finally talk about the redesigned products. At least one of the posts will talk about some of the software I’ve been using, and I might touch on a fairly academic subject which is the problem of incorporating design projects into a PhD, something I’ve had to pay a lot of attention to in the last few months.

Before I start, I should draw attention to Brian Ling’s Un-p3 project over at Design Sojourn. I actually included this project as part of my PhD application to explain the kind of thing I was interested in researching – the act of appropriating and redesigning existing products. Even though his reasons were somewhat different to mine, the Un-p3 project has continued to be an inspiration (and a help – when people ask what I’m doing I can point them there!).

Microsoft Comfort Optical Mouse 1000

What I’m Doing, and Why

This part of the PhD started from a need to define what time period my research is focussed on. I developed three scenarios, a short term scenario (0-5 years), a medium term (5-10 years) and a long term one (10-20 years); and wrote about the possible state of consumer design and manufacturing at those time scales. The problem, even with the medium term scenario (and especially with the long term) is that they quickly and easily became ‘science fiction’. Either you agreed with the scenario and the directions the technology might take, or you didn’t. I would have been able to present research to back up my assertions, but it wouldn’t have proven anything, only made my assertions a bit more credible. And it seemed to me that the research direction would inevitably have been more about testing and proving the technology, rather than doing actual design. There have been a number of assertions from different directions that rapid manufacturing technologies will allow consumers (ie people who aren’t trained as designers) to design and manufacture their own products, but there’s not much in terms of ‘facts on the ground’ to show how this might actually happen. Basing the research on a future scenario side steps the issue somewhat, by relying on some magic technology that solves all the problems. By basing the research on the current day situation, it introduces problems that might otherwise be avoided, but if they can be solved then it makes those assertions more credible.

A good example of this is the way I’ve chosen to reverse engineer the product, which is to use only the kinds of tools that a non-specialist might have, or at least be able to get easily if they were interested. This introduces a whole number of problems which I’ll talk about later, but are primarily to do with accuracy. These problems could have been avoided if I had argued that in future everyone will have access to 3D scanning technology. But if I’d done so I would have been drawn into arguments about when 3D scanners will be accessible, after which there would be questions about how easy they are to use and how useful the cloud-point data they produce would be to an untrained consumer. And to satisfy the PhD I would have needed to test various scanners and software with consumers and decide which ones have the most potential for use by non-specialists and even then not convince everyone (including, probably, myself). That’s not the route I wanted to go down at all, so by sticking to some basic, existing tools I’ve hopefully avoided the argument and can concentrate on the design aspects instead.

The tools that I used: vernier caliper, ruler, mini screwdriver set, torx screwdrivers, scalpel and anti-static bag

But I’m getting ahead of myself a bit here, first I need to describe the scenario I’m working in… The timescale is from the present day to five years in the future. The computer hardware that a consumer might have access to is essentially the same as today (obviously there will be improvements in performance, but I’m not relying on them to make the scenario work). Digital manufacturing technologies are accessed through services such as Ponoko or Shapeways (again,  in five years time there may be other services which are cheaper or easier to use or whatever, but the scenario is still credible even if nothing changes). Given those assumptions, what I’m proposing is that the opportunity exists for an ‘expert amateur’ to take an existing product, reverse engineer it using some basic tools, and reconstruct it in CAD. If that’s possible, then those CAD files could be made available for anyone to download and manufacture a copy. So this part of the project is about proof of concept that reverse engineering a product, a computer mouse, is possible.

There are a few questions which inevitably get asked at this point. Firstly, hasn’t this already been proven by models on Google’s 3D Warehouse or Turbosquid? Well, yes and no. Those models show that a degree of reverse engineering is possible, but not to the extent that I’m talking about. Because the models are mainly intended to be used visually, either on-screen or as printed renderings, they don’t have anything like the mechanical integrity needed to make a functioning 3D part. There is no guarantee of dimensional accuracy beyond what’s needed to look realistic, and certainly no consideration of how to assembly a ‘real’ product. 3D Warehouse and Turbosquid show the feasibility of a repository for models, and hint, perhaps, at a market, but unfortunately nothing more.

The next question is why would someone want to manufacture a copy, given the expense and (poor) quality of rapid manufactured parts. This is a difficult one, and so I avoid it by saying that’s not what I’m researching! Actually that’s not strictly true, I am assuming in my PhD that rapid manufacturing technologies will improve in quality as well as becoming cheaper, simply as an inevitable progression. I’m not about to put a date on when it will be possible to produce high quality, affordable parts. But if reverse engineering (and as a consequence, consumer design or customisation) are possible now, they will still be possible when the technology ‘catches up’. For now I just want to show that the scenario is feasible.

Rear of the packaging

Finally there is the question of legality, and all I can say here is that it’s a grey area that I’m only beginning to touch on. Inside the box that the mouse came in there was an EULA which prohibits reverse engineering Microsoft’s software drivers, but nothing covering the hardware. That probably indicates nothing more than the likelihood of it happening though, which is obviously pretty small. Adrian Bowyer of RepRap has co-written a paper looking at the intellectual property implications of 3D printing (free download, and definitely worth reading if this kind of thing interests you), which suggests that, in the UK at least, personal use of 3D printing technologies doesn’t infringe the majority of IP restrictions:

“Registered design and patent explicitly exempt personal use, trade mark law has been interpreted as doing so, and UDR [unregistered design right] is only applicable to commercial use.”

This non-infringement is especially clear if the parts can be considered as spares needed for “the repair of a complex product so as to restore its original appearance”. What Bowyer’s paper is less certain about is the legality of making 3D files available for others, stating that “Judicial or legislative clarification may be required to settle the question of whether a patent is infringed by providing instructions allowing a 3D printer to make it.” As I said, it’s a grey area…

I recently received a mail from Alex Mamalyha, web community manager for i.materialise, announcing the launch of a new service from Materialise NV. i.materialise is a rapid manufacturing service aimed at designers, and the beta site gives a good idea of the way the service will work. Obviously there are many web-based rapid manufacturing services these days, and the announcement of a new one is a fairly regular occurrence which I usually just ignore. But given the extent to which Materialise have supported and encouraged designers’ use of RM technologies through their .MGX initiative, I thought this was one service that deserved further investigation.

The ‘manifesto’ of i.materialise claims the service makes “3D printing as easy as printing on paper”. Obviously such claims owe more to hyperbole than fact, but the i.materialise interface is presented in a relatively simple and obvious way. A workspace in the centre of the screen visualises the model once it is uploaded, and a number of drop-down menus to the right give the choice of materials, surface finishes etc.

To test the service, I used a model I made previously for Nina Pirhonen, a Finnish designer and creator of the PomPom character and series of books. The model was originally created in Solidworks, but in order to upload it to the i.materialise site it first needed to be converted to .stl format.

3D model of PomPom © Nina Pirhonen

It’s here that some of the limitations of the i.materialise service first begin to show. Whether it’s to simplify the operation, or because limits don’t in fact exist, there’s no information regarding maximum file sizes or number of triangles/polygons. This is fairly basic information that anyone, designer or not, with the skill to create a 3D CAD model will want to know, since it has a fundamental effect on the quality of the manufactured model, and most CAD packages allow the quality of the .stl file to be easily determined. In this instance I used a relatively coarse setting, giving a triangle count of 20,024, and a file size of 1,001,284 bytes. I also imported the file into Rhino in order to export as .3ds, .obj and .wrl formats.

Exported .stl model of PomPom © Nina Pirhonen

Uploading the file is easy – click the upload button and choose your file – and quick; a 1.5Mb .3ds file took about 20 seconds to upload, with a further 8 seconds for the i.materialise software to analyse the file. Exactly what the analysis involves isn’t clear, but I assume the model is being checked to ensure it’s a closed volume. No errors or warnings were given about the model, which suggests it isn’t being checked in terms of the feasibility of it actually being made – the ears, arms and feet/ground of this model would definitely throw up problems, particularly in some of the more fragile material options. Once the model is uploaded it appears in the workspace of the user interface, and can be viewed from different angles.

i.materialise interface © Materialise NV (click for larger image)

Another limitation of the interface is that there’s no option to change the build orientation of the model. Since most rapid manufacturing technologies have different resolutions in their horizontal plane and vertical axis, this can be an important choice, affecting which surfaces have the smoothest finish. For a service aimed at designers it’s definitely an option I would expect to see.

On the right hand side of the interface there are a choice of materials, including ABS, polycarbonate and polyamide, alumide, and multicolour composite. As different materials are chosen the price automatically updates, along with the surface finishing options. Most materials can be painted and some can be mechanically smoothed (similar to tumble polishing). There’s also an extensive ‘library’ of information about materials and manufacturing techniques.

Multicolour Composite material properties © Materialise NV (click for larger image)

Given the nature of the model I was testing the service with, I was particularly interested in the multicolour composite option. Materialise use a Z Corp Spectrum Z510 for this process, which prints at 600 x 540 dpi. The problem was that, as far as I could tell there is no way to specify the colour of the surfaces. Usually Z Corp Spectrum printers use VRML files, but when I uploaded in this format (the system accepts and recognises .wrl files, even though they are not listed as a usable file type) no colour information was retained. The same was true when I tried an .obj file. Looking around the site and through the FAQ’s didn’t give any clues as to what file formats I should be using or whether this option is functional, but obviously this is something that needs to be fixed before the service comes out of beta testing.

All in all, I’m not really sure what to make of the i.materialise site and service. It’s stated explicitly that the service is aimed at designers, though it’s not made clear whether that means just design professionals or includes consumer-designers. Either way, for those with the experience and skill to create their own 3D models it seems a bit simplistic. There’s none of the control you get setting up a model for printing yourself, particularly deciding what orientation the parts should be printed. To be fair it’s possible to contact i.materialise direct, but then the service becomes little different to using a local RP/RM shop (although admittedly, the range of materials and processes is much greater than most shops are able to offer). And of course it should be kept in mind that the site is still in beta testing, the whole point of which is to iron out the glitches. In this respect at least, i.materialise have done a good job – the UI is easy to understand and the whole process of uploading a file, choosing a material and ordering is easy to follow.

Finally, one tantalising option, which isn’t possible to review but which is suggested in the FAQ’s, is the future possibility of ordering some of the .MGX designs. Quite how this will work is unclear – will it simply be possible to choose from a catalogue and hit ‘print’, or will it be possible to modify the design? But this is obviously one area where the i.materialise service can offer something unique, over and above similar web-based services or a local RM shop.

Update: Since posting this article I have swapped a few emails with Alex Mamalyha; my questions and his answers are reproduced below:

1. Is there a maximum file size, and is there a limit to the number of triangles or polygons in a model?
2. How are colours specified when choosing the multi-colour composite option (using the Z-Corp Spectrum printer)?
3. Will you attempt to make any model, or will you advise if an uploaded model is unsuitable?
4. What is your returns policy?

Finally, I noticed that it’s possible to upload a VRML (.wrl) file and the system will recognise it, but this isn’t listed in the ‘supported formats’ list.

1. There is no limitation on the file size or number of triangles in the model.
2. Colors should be stored within the uploaded file, so if you choose Z-Corp we will print it in color (I realize it is a bit confusing since the preview generated images are in single color, but we will improve that bit shortly).
3. We did some testing with Blender users. If the uploaded file is not suitable for printing we will fix it ourselves, unless it requires severe design changes (after all we don’t want to print cube when the person is ordering sphere) in which case we will contact the designer and explain what has to be changed. We will not attempt to print something that is not printable. Additionally, we are developing plug-ins for major CAD programs that will provide designers with the info on problems with the file before they even upload it.
4. Once we print and ship the model, it cannot be return for obvious reasons (usually it’s one of a kind design)

About VRML support. We are still in a pretty early BETA and some info may not be consistent in all parts of the website, but we will do our best to provide support for a number of different file types.

Are there plans to add functionality which would allow the designer to choose the orientation of the part in the build chamber? Or maybe make it clearer which is the Z-axis so the part can be oriented in the modelling application?

We are working on functionality, so that preview window on the website will allow designers to rotate the model, rather than have screenshot generated (as it does now). It does not matter how the file is located during the upload process, we have support engineers, who check all incoming files and position them, we don’t expect people to know how the model should be oriented for printing purposes.