The main problems i’m having are due to using other people’s software. I don’t know exactly how Poser deals with bones, I don’t know exactly how Rhino goes about BooleanUnioning etc…Tiny discrepencies of 0.000001 units, an invisible pin prick, can cause a fatal problem in terms of achieving watertightness.
Rather than a figure being made up of 30000 floating vertices to 7 decimal places of accuracy, what about converting the figure to an array of tiny cubes? This way i can be sure of where everything is.
Each surface on the model can be converted into a list of 3d cubes. Any overlapping polygons (which cause big problems in BooleanUnioning) are irrelevent as they will just contribute a cube which is already there. Each cube can be given a unique color extracted from the appropriate texture map. Importantly there is no need for any Boolean Unioning – each poser figure from a sequence is just bunged into the program and all its vertices in turn either contributing new cubes or not.
I have an OBJ file exported from poser which consists of a list of vertices and faces. i wrote a program to parse through this and switch on or off a grid of cubes using a cubes[x][y][z] array. here’s the first image using a grid approximately 100 cubes high.
So the program works.
Once the cube array is created the second part of the program goes through the array and if the array element is filled then it writes a new cube object to a new output OBJ file. There is a little fiddly-ness here as if you want the cube to render properly in Rhino you need to make sure all the individual cube faces are pointing the right way – that is outwards. you do this by giving each face a normal – a direction vector pointing out of the face, and here we effortlessly drift into the world of 3d geometry (abandon hope all ye who enter here). here is an OBJ file of a single cube:
v 0.0 0.0 0.0
v 0.0 0.0 1.0
v 0.0 1.0 0.0
v 0.0 1.0 1.0
v 1.0 0.0 0.0
v 1.0 0.0 1.0
v 1.0 1.0 0.0
v 1.0 1.0 1.0
vn 0.0 0.0 1.0
vn 0.0 0.0 -1.0
vn 0.0 1.0 0.0
vn 0.0 -1.0 0.0
vn 1.0 0.0 0.0
vn -1.0 0.0 0.0
f 1//2 7//2 5//2
f 1//2 3//2 7//2
f 1//6 4//6 3//6
f 1//6 2//6 4//6
f 3//3 8//3 7//3
f 3//3 4//3 8//3
f 5//5 7//5 8//5
f 5//5 8//5 6//5
f 1//4 5//4 6//4
f 1//4 6//4 2//4
f 2//1 6//1 8//1
f 2//1 8//1 4//1
Not too bad – the faces are the f lines and each one consists of three vertices so the last line says make a triangle and gives three references to the vertices (v lines) and vertice normals (vn lines).
(The triangles are the convention and should be useful later when coloring and saving as an STL file.)
Here’s some more shots of the simple pixel man with correctly aligned faces.
Of course this process radically alters the aesthetic of the work in ways i’m chewing over, as they are not what i originally had in mind. The massive benefits are that I have control of the process. The sequences created can be huge – only limited by memory, as filling the arrays is fool-proof (?) and speedy. the figures above took seconds to create. Also there is no fannying around in Poser and Rhino, just export the animated sequences as long as you want and run the pixel program.
Another benefit is that if i desired to create continuous motion (as opposed to the discrete stuff coming out of Poser) then this could be simply handled by taking two sequential OBJ files and creating a third set of polygons which connect the one to the other (the in-between stuff) which the pixel program would munch up easily. Remember the beauty of this approach is that it doesn’t matter if you have polygon overlaps – the cubes are only either on or off.
the drawback is that i’m changing the aesthetic of the models – they now become more abstracted, i’m still not sure if this is good or not. If i could up the resolution of the cubes this may or may not help (but that has its own problmes – see later).
Here’s one done at a higher resolution (1 cube = 1mm):
So here’s the first issue – the cubes only appear where the vertices are – they do not cover the whole polygon face – and as a result we have what looks like a point cloud – but at least the detail is there – as opposed to the pile of bricks-ness of the previous figure.
The first issue is one of memory. If i wanted to construct a figure made of cubes which were 1cm across then for a standing pose (about 200cm * 100cm * 100cm) would involve 2,000,000 cubes. Two million cubes is handled OK in terms of memory but if i want to make the scale of the cubes equal to 1mm on each side then the number of cubes would go up to 2,000,000,000 (20 billion) and this is too big in terms of 1)computer memory and 2)calculation time. the coding solution to this is to not use an array (a lot of which is going to remain empty and unused) but to create a list of cube locations. Each time we want to add a new cube (from a new vertex) we check to see if it has been added already. If it has we ignore it, if it hasn’t then we add to the list. This checking will slow the program down but as a Poser 6 figure has about 30000 vertices the model can still be made in about 10 seconds. Each additional figure in a sequence will add ten more seconds – so OK. If i wanted to do one for 100 animation steps walking across a room then the resulting list would get longer and longer – but i think this will be OK. I’ll definitely need to look at removing redundant faces at some point, but this shouldn’t be too bad as everything is on a grid.
I have the 4 vertices which make up a polygon face on the figure = 4 cubes. next i need to fill in every cube which intersects with the face – and this can be done using 3d maths but it isn’t pretty. the specific method used is the Voorhies Triangle-Cube Intersection Algorithm which can be found in Graphics Gems III which in turn uses 9 triangle-square intersection tests – and will slow the process down a fair bit. This coding is really getting into the meat of 3d maths and is the type of thing used to tell if a bullet has hit you in Doom. I deliberately have avoided this sort of code so its an interesting challenge.
These models need again to be watertight (even if they are cubes). I think here i might be able to write algoritms to check for this – as cubes are on a grid it makes things easier. Will need to develop some sort of inside outside concept – should be fun. This is the make or break of this idea. Also it is not clear to me that if you have 2 cubes which touch at a single edge – then will this rapid prototype OK – or will the 2 cubes just fall apart – i’ll need to check this out too. As I’m going to make a full size figure user laser-cutting of something cheap like cardboard i’ll also need to know whether it is OK to have redundant inner cubes floating around – ie: does the skin need to be thick and hollow.
I thought his might be easy but no – the OBJ gets its color from a x,y coordinate on a texture map (a JPG). I’m not clear exactly how the texture is appled to the face polygon – i would hope to simplify this so each cube is a solid color to match the abstracted aesthetic.
Even if i can’t solve the above issues this program will be very useful in terms of visualising any particular sequences that i export from poser. Peter said that some motions which look good in real time generate boring 3d models which is interesting. This program may help to choose which models to render fully. Besides its fun to finally have my hands on the actual data and mess around with it, although whether i spend my entire year coding (for no pay) rather than making art is a dilemma.