WikiHouse SketchUp Plugin

[tav]

Hey all,

First of all, let me say that it's great to see activity on this mailing list. We have long dreamt of a community springing up around WikiHouse and it's really nice to see the seeds of an emergent community!

Now, with regards the SketchUp plugin, it is important to understand that it was intended primarily as a proof of concept. Nevertheless, the code is reasonably documented and the use of clear variable names will hopefully make it accessible to the hackers amongst you:

• https://github.com/tav/wikihouse-plugin/blob/master/wikihouse.rb
  

Alastair already covered many of the aspects of the plugin in his previous email, but it might be worthwhile going through some aspects in more detail:

• The plugin only creates SVG output at the moment. I had intended to implement DXF support too but never got around to it. Implementing this will be a very easy task if any of you fancy taking it on — a day's work at most. For it to work, all you would need to do is implement the WikiHouseDXF.generate() method. Right now this is simply a stub that returns empty file contents. It'd need to return the DXF data instead and you can look to the existing WikiHouseSVG.generate() method to figure out how you would generate that data from the @layout parameter the class is initialised with.

• Likewise generating the G-code to handle most NC machines would also be similarly straightforward. Just define an additional WikiHouseGcode class with an appropriate generate() method and call it in the same places that WikiHouseSVG is initialised/called.

• Adding support for ISOCPEUR font for labeling would be another easy win — about a day's work again. You can easily convert the font file to get the vectorised paths for the different unicode codepoints and convert them into SVG and DXF output. The real question would be around the legality of this — someone should contact the foundry (Autodesk?) and enquire.
  

• Deciding where and how to put the label is a slightly trickier problem, e.g. having meaningful labels, rotating them, properly, centring them, etc. Whilst implementation would only take a few hours, this would require a couple of days of thinking.
  

• Doing efficient nested layouts onto sheets is a lot of fun but also fairly complex. Having read up on the literature and after doing extensive experimentations, the "simplest" algorithms are ironically the most efficient. That is, "intelligent" brute-force layout algorithms achieve greater efficiencies than more intensive mechanisms like genetic algorithms. I've implemented the start of one such algorithm and it is encapsulated within the WikiHouseLayoutEngine class. With about a week's worth of love, this implementation could do significantly better. But it would still be hard to beat manual layout by a person due to limitations of the SketchUp API and the Ruby VM not being that well-suited to number crunching.
  

• There are also lots of tiny details that could do with cleaning up. These have been marked "TODO(tav)" in the source code. So feel free to grep for that and fix them.
  

If any of you fancy taking on those aspects, I'll happily look at Pull Requests on GitHub.

The real question is whether it is worthwhile investing time in the SketchUp plugin. I developed it as far as I could afford to in my free time, but given the limitations of the SketchUp API and the Ruby VM for number crunching, the SketchUp plugin can only go so far.

I have therefore been spending my free time developing Ampify: an open source, decentralised application platform more suited to what's really needed. The intention is to then build an in-browser WebGL editor for semantically-aware, parametric 3D models, i.e. without any software/plugin downloads.

The editor can then support the kind of API that's needed to make the design-cycle, collaboration and manufacturing revolution of WikiHouse a reality — with backend cloud servers doing the number crunching needed for efficient layouts, etc.

There are players like Sunglass, Tinkercad, Grabcad, etc. who are doing similar WebGL-based in-browser interfaces, but none of them are open source or suited to the specific problems that WikiHouse sets out to solve. And whilst Ampify is a fair way from working, I hope it will act as a viable platform for this one day.

In the meantime, of course, do feel free to improve the SketchUp plugin!

P.S. Why is posting via email disabled?

-- 

Many thanks, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369

http://tav.espians.com | http://twitter.com/tav | skype:tavespian

[John Bacus]

Hi Tav,

Lots of things have happened on the SketchUp team in the last eight months or so, and I'm pleased to be able to contribute to projects like this again. Last fall we dipped our toes into open source development with an stl import|export extension, and the project went quite well from our perspective. I look forward to finding ways of working together with you on the WikiHouse plugin. I'd be keen to hear more about your Amplify project— but that shouldn't preclude us from working together to get some of the simple stuff done in SketchUp. I hope you'll be surprised by what can get done with our simple little tool ;-)

I'll spin up a requirements doc from our team's perspective— we're keen to help where it is appropriate to do so. I'll also dip into GitHub to collect requirements and post FR's as we go forward. Some of our eng folks have already dipped into the code a bit to see if we could fix the javascript errors that are preventing folks from downloading models. There's some really clever stuff going on in there :-)

john

.

[Chris Musselle]

Hi Tav, 

Thanks for the summary. And I'm glad to hear a lot of improvements could be made with what sounds like only a moderate amount of effort. Though as I only picked up Ruby and the SketchUp API a week a go, it may take me a bit more time getting used to working with the code. But do expect some pull requests from me in the future!  

Could you elaborate a bit more on the limitations of SketchUp API / Ruby VM for number crunching, I am assuming you a talking about numerical precision here? Or is it just the speed of numerical computations in general? I would have thought this is something that would/could have been addressed with a Ruby extension or plugin. (Note, not an expert here at all, just know that from my experience of using Python for scientific research, that there are lots of libraries available for numerical work written in lower level langages like C.)

Also, with regard to developing a web-based editor using WebGL, as an interim you may find this this plugin of interest. It uploads/converts SketchUp models to sketchfab, a site that shares 3D models for free using WebGL, which could them be embedded in your own websites.  

Many thanks.

Chris

[Alastair]

Martin Luff's forwarded message: 

"Hi Tav

Very much appreciate the overview - helps clear up a lot of questions :) 

Sounds like Ampify will be the dog's dinner - but also a big commitment in coding time...

NZ team have big questions over Sketchup; very much understand why core team went with this in first instance to facilitate access to tools at all levels but in the end it's still not an open product - plus seems to be costing us precious design time since not ideally suited to the task. Some alternatives (still not open) offer a number of potential benefits at not much more financial cost (took us a lot of effort to secure a few not for profit licences for SU Pro) plus backward compatibility to certain degree through export to skp format. 

We're experimenting with Rhino right now for a few reasons - but interested if you had any view on Rhino Python being any better than Ruby for scripting in this context? 

Kind regards

Martin"

[Alastair]

So you guys have already covered a lot of detail on this, I just wanted to throw in my two penny's worth on the plugin, and specifically on the rules of nesting.

Nesting 

First, this dxf file is a fairly good illustration. It was nested manually. The hardware system has, over time, been evolving to result in pieces which fit better onto sheets anyway, and hopefully will improve even further still. When you're doing the job manually (which is still better than the script but far from perfect), there are a few semantic rules going through your head, which I thought might (or might not) be of use/interest:

1. The blindingly obvious one. Big parts first, little ones fill in the gaps. Our latest version has lots of identical small pieces which is really good for this. Rocks, then pebbles, then sand.

2. Unless its automating straight to G-code, then one of the economies is consolidating sheets so there are as many 'repeats' as possible on the dxf, to save on CNC programming time. If there are two large or medium sized identical parts, don't put them on the same sheet, put the second one in the same place on a second sheet and repeat until there are as many identical sheets as poss.

3. The L-shaped corner pieces are the tricky ones. A good trick is to put L shaped pieces rotationally opposite each other on sheets. This very often results in spaces in between which other parts can fit into. I don't know why it works, but it often does. This might be a human workaround which isnt actually the smartest way of doing things. Others can probably infer better rules than this.

4. Naming of parts should always be as semantic as possible (so the designer can work out the most intuitive naming and numbering system for their house - like in-build instructions: 'building by numbers!'), and some (e.g pegs) are so frequent they don't need naming. They currently only take a name if the Sketchup component has been named in 'Entity info' and I think that's right. In an ideal world the names might always tend to land on the same face of the house, so they are all pointing the same way during assmbly (minimises risk of mistakes), but thats not essential, and if automated nesting can be done by allowing parts to be mirrored as well as rotated, then it's probably more important? With parametric geometry generators, all this might go a bit 'meta' since each system would have a designed naming system, rather than each individual house.

Layers 

There's a lot of scope for change on how and whether the output involves layers in the same way as the linked example dxf does - they certainly are valuable I think if manually programming from dxf to CNC. Those layers at present are:

1. The sheets outline (1200x2400, despite the fact that in UK they are still in imperial, 1220x2440, though this could be a user-set parameter)

2. The outline of the parts.

3. The inline of holes in those parts.

4. Shallow routing into the surface of parts for marking the names / numbers onto them.

5. We haven't yet found a way of automating small holes well from Sketchup (it only does polygons so its massively memory intensive, for one thing, so if it is done its better modelled with 2mmx2mm squares). But in theory there might be a layer for small 2mm diameter pilot holes all the way through, for the screws.

and I would ideally add a sixth.

6. Half depth (9mm or even a designer-defined depth) routing within some lines, to allow channels to be routed out of sheets. No clue how this would be automated from the model. The mind boggles. Might not be possible.

Those layers are cut roughly in reverse order (but thats not a perfect rule, eg.When parts are placed inside large holes in other parts. CNC software tends to be pretty clever knowing this!). I think Danny also raised the idea of making 18mm as the sheet thickness a variable parameter.

I hope that makes sense and is in any way useful. It's all subject to change of course, but... that's how we've been doing it so far. You other CNCers, please do share if you have some more sophisticated 'rules of thumb' than this lot! It may be that user inputs are still required, so rather than attempting to entirely automate from sketchup to cutting file, a half-way interface is used, which allows the designer to help the script know what is what?

A

[Harvey]

Hi All,

great project thanks for this

I just wanted to post a link to some information on nesting algorithms which might be of some benefit

The accepted answer on this StackOverflow question provides some links to PDFs which I found useful in understanding how various algorithms work ...

http://stackoverflow.com/questions/2675123/nesting-maximum-amount-of-shapes-on-a-surface/

Regards,

Harvey

[Danny Squires]

Hi John,

I notice that SketchUp is now listed on the home page as a wikihouse supporter - just wondering what support you are able to provide?

Last year we had been able to negotiate 3 educational licenses for Sketchup Pro for the WikiHouseNZ team (this occurred during the time of the handover from Google to Trimble - our request was initiated by Craig Nevill-Manning when he was here for the transit of Venus lecture and eventually facilitated by Christopher Cronin). Due to the handover it took many weeks (and emails) to receive the license codes after the initial request was approved - these have recently expired and now we are unable to use it. 

When i went to quickly re install SketchUp 8 (free version it informed me I had to uninstall Pro) I guess we could download Make and re-install but will lose custom settings & plugins.

Can you suggest any better options? I can email you the serial numbers and previous correspondance if that helps?

Regards

Danny Squires - WikiHouseNZ | Space Craft Systems