30_slugman

The aim was to produce a cardboard build-it-yourself model of a man walking. This would be packaged in a plastic bag and labelled like a toy kit and this could be handed out at the House Gallery or other shows as a sort of promotional pack. This was partly inspired by a Cardboard Safari model my brother bought for me of a Rhino head. The rhino slotted together and is about 2 foot across – I was aiming to make a much smaller model (perhaps 20cm high). Working out how to construct the slotted model (ie which slices could be effectively slotted together to reveal the form) was very very difficult and defeated me – so for now I’ve just made a sliced model which is glued together.

slugman0

The Source

I had a walking man exported from Poser as a series of OBJ files. 0-63 which represents two full walk cycles where the body returns twice to its starting position. I had planned that the models made would be modular – that is they could be combined together to make a extensive walking chain – this is something for the future – although the chain idea is good it means that each individual model has an unnatural start and stop slice – as this has to attach to the next model. working out how to make the model work both as a middle and end piece will be interesting. Perhaps these will be two seperate models. For my simple model – called Slugman (“he leaves a trail”) – i needed just 5 OBJ files in the end. These were spread out 0,3,6,9,12. I determined these frames by looking at various combinations in Rhino. Too many frames and the individual positions of the arms and legs all blend into one – too few and we lose the sense of a trail in 3d space. the balance seemed about 5 frames.

tidyobj.java

The OBJ files coming out of Poser are ‘messy’, that is they include polygon face lines [f] for a lot of mesh body parts which have no bearing on my models. Eg interior organs, tongues, teeth, fingernails etc… I wrote a simple java program to remove these lines, by looking for the [usemtl] tags and then ignoring those i don’t want. This could be improved by also removing the vert [v] lines that aren’t used but as these are only to be sorted out through their associations with the [f] lines i’ll do this another time.

voxelizer.java

to get a rough idea of what the model might look like as a solid i ran it through voxelizer.java (almost the same program as used on the yes-no heads). This asks for a scale and then creates the object using cubes to this scale (equivalent of a resolution). The image is here:

this helped to determin which OBJ frames to use. 5 seemed about right. at this stage i wasn’t clear how the AI files (as this is what the laser cutter needs) would be rendered. AI (Adobe Illustrator) are at their simplest just a series of coordinates which define a series of vectors or lines which make up a shape. For example:

96.0 48.0 moveto
100.0 48.0 lineto
100.0 52.0 lineto
96.0 52.0 lineto

and these files could easily be written on the fly by the programn. If this was the method to use then the output AI slices would have a jagged pixelated edge making the final model somewhat voxelized – so this program would have been more useful. it turned out i used a more involved combination of computer program and hand drawing.

wrong step

the next stage was to work out how to produce the slices. i went through two main possible routes

1) outputting slices as SLC files from rhino – then grouping slices, and screen grabbing these then attempting to trace these in Illustrator. This method was extremely frustrating as each trace involved multiple arbitrary decisions about what to leave in and out, and how to clump the slices. As this method was abandoned i won’t go into too much detail – a wasted 3 days. it did however lead me into the current direction, which works judging from people’s feedback. the key to the problem was in which axis to slice – i had to abandon the idea of slotting together the slices at this point – unfortunately the rhino head above is a pretty solid 3d shape (and recognisable in several profiles), my model is very unclear what’s happening if you slice in the wrong direction. as i’m looking to emphasise motion it seems natural to slice in the direction of motion – this is eventually what i did – but other slices have benefits of bringing out multi-leggedness. so this failed method lead to;

2) voxelizing the figure – and outputting multiple OBJ files which could then be converted to AI files.

So once again back to the cube route – where i know where everything is!

slicer.java

this program is the one that takes all the OBJ files and converts them into a big array of 3d cubes and then outputs whichever slices i want from the cube. in this case i wanted under 30 slices as people were going to have to glue these together to make the model. all the slices needed to fit onto (or be cut out of) an A2 cardboard sheet.

minmax.java

slicer.java is a rewrite of voxeliser.java, the main difference is that the program uses a 3d array from the start rather than adding filled cubes to a 1d array or a list as you might as well call it. for different cases one of these approaches is more suited and this is to do with memory. a 3d array of size 100*100*100 takes up 1 million slots of memory which my machine can handle OK but as the model gets bigger then the memory can run out. i wrote another program called minmax.java to search through all the vert data from all the OBJ frames in a sequence and store the minimum and maximum x,y,z coords that it finds. then it outputs these along with suggested array sizes given different resolutions. as a 1mm cube resolution occupies 1000 more memory slots than a 1cm cube resolution it is important to try and get the scaling right here before the program runs out of memory. i’ve decided that a scale or 1 cube = 1cm per side works well. making a Poser model under 200 cubes tall. (NOTE: there are ways to allot more memory to the java compiler but these have proved tricky so far.)

The eventual sizes were:

static int sizex = 71;
static int sizey = 193;
static int sizez = 180;

now the z coordinates will be translated into cardboard slices – each one about 3mm thick – this worked out at 26 slices about right. the slicescaler was at 6 z units per slice.

so slicer.java converted the [f] polygon face lines into vert coordinates (by making a box around each face and checking if each cube in the box intersects with the face. (NOTE: this is an efficient algorithm but i’m not sure it is the quickest – couldn’t i just send proportions of the face vectors???) – to fill an array of cubes. then i scan through the array in z+=6 and output as OBJ files where each cube is drawn not as a cube but as a small square – an idea to improve this is to only draw squares which aren’t surrounded by other squares, this would make the OBJ files smaller and easier to convert and open in AI. here is an example, although it is flat it is still an OBJ file.

obj2singleeps.java

So i have 26 OBJ files and i need to convert these directly into AI files. AI are basically an extension of EPS files (Encapsulated Post Script) or even more simply a list of coordinate pairs with [moveto] or [lineto] to create lines. I wrote a relatively simple program to gut the coordinates from the OBJ files and draw small squares onto the EPS files. The only clever part is that all 26 shapes are drawn onto a single EPS file which ended up looking like this:

Now i was getting somewhere: On the left is the solid square filled shapes – on the right i’ve created a new layer in illustrator and used the pen tool to roughly trace around the figures by hand. this gives the slices a natural hand drawn feel which i think i’ll go with for now. This sounds easy enough but as usual with any new piece of software (particularily Adobe) you’d imagine the interface for drawing lines would be intuitive and obvious – it isn’t. there are some other free vector software tools which people recommend – still the output file has to be Illustrator AI legacy version 8 or the old laser cutter has difficulty.

Finally the shapes were ready for laser cutting.

There were no great problems here at the 3D resource centre at camberwell. the technician took the AI image and we scaled it to fit the card i’d bought in. I cut 3 copies each one taking about 5 minutes. We had to calibrate the speed and intensity of the laser cut. too strong and the laser beam can set the corrugated cardboard on fire, or leave scorch marks. The right settings turned out to be:

card 3mm
velocity 3.5
power 80

These models were displayed at the House Gallery Feedback show, December 2008.

The positive feedback to these models encouraged me to take the design a stage further. I increased the size of the AI model and simplified/abandoned some of the smaller parts. Finally i placed them onto the large A2 sheet in 4 A4 sections which would also be cut out by the laser cutter. I was aware that by increasing the size of the model from 10cm to 16cm should imply that the width (or number of slices should also increase by 160% or 40 slices, to retain the overall proportion, but as fitting all these onto the 4 sheets would require a brand new set of outputs i decided to stick with what i had. i cut these out and then built a model to compare. To fit them onto the 4 A4s i manipulated them around by hand in illustrator.


The main difference which i hadn’t even factored into the equation is that the new models are cut on a different grain that the first lot – so formthe side you can see through them. On balance i prefer the more solid look of the first set – but they both have there positive points. i’ll be making a third set next term. i designed a label for the models with an assembly diagram and packaged a few up. here’s the final prototype product.


Next term is an important exhibition open to all UAL students called EXHIBIT09. the selected 30 or so students are shown in the Davies Street gallery over the course of a month and it’s an important showcase for graduating artists. Luckily the theme this year is SUSTAINABILITY and as my models are made of recycled corrugated cardboard i think they might fit well. i intend to make a modular slottable version of the slugman (perhaps a cardboard army?) at the beginning of next term which can be assembled by people attending the show. the models can be interlinked forming large chains. i may need to make a start and an end model too.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: