I eventually gave up on the fingerprint scanner as a lost cause and defaulted to the classic fingerprinting method of ink on paper. Even then it was a lot harder to get a usable print than I would have thought. My fingers would always either be too wet and the lines would blotch together or the ink would dry too much and not leave solid lines at all. They always make it look so easy on TV. I don't know, maybe the ink-pad I bought wasn't the right kind, and there's something special about ones you take fingerprints with. I don't think fingerprinting was it's intended purpose.
When it came to actually making the model, I was disheartened to find that there was no easy function for drawing three-dimensional shapes in processing, which basically meant I would have to do a lot of trigonometry. I had to use the pushMatrix and popMatrix methods to move and rotate the coordinate plane around, and then always draw a triangle on the x-y plane, which means I had to create some arrays to hold the distances between points both vertically and diagonally, which would change based on a given points elevation (which itself would be taken from an array whose values would depend on the referenced fingerprint image). If two adjacent points were wildly different in elevation, that side of the drawn triangle would need to be longer, etc.
I had a really hard time debugging this project. I think a lot of it was that I spent so much time checking and re-checking my trigonometry that I overlooked a lot of problems that didn't have a lot to do with that. For a long time I couldn't figure out why the upper-left set of my triangles between points would seemingly diverge and curve away in a plane away from the lower-right set of triangles, so that instead of one solid landscape I'd have two diverging sets of shrapnel. It turned out I only ever had the triangles turn in one direction, so that they'd turn up when there was a mountain, and then when there'd be a valley, instead of turning downward, they would turn upwards again.
I had to make a tic-tac-toe-sized grid on a model to figure out exactly what was wrong. I also used it to work out the order in which to do the transformations that enable the model to be navigated, so that everything's done in the right order and the camera movement works like expected.
The version I actually turned in utilized Processing's box function to act as a three-dimensional pixel in rendering the landscape. In order to get a smooth transition between the peaks and valleys of the fingerprints I ended up having to actually manually blur the edges of the black-and-white fingerprint images in Photoshop, so that when the program read the image to calculate elevations and calculate the shifts in color for each 'pixel', there'd be no abrupt transitions. I tried to work out an in-processing way to alter the fingerprint image to get a similar effect, but nothing I tried worked very well.
A sample of the fingerprint image I used:
I would have liked to have been able to use a higher resolution image to sample from, so that I'd be able to make larger dunes in the fingerprint landscape without getting too boxy, but the performance speed was pretty horrible even the way it was.The trigononometric-landscape I developed ended up with a lot of cracks in it between triangles due to rounding, and I ended up making a single, flat, skin-toned rectangle underneath everything to mask them a little bit.
And then, of course, I realized that you *can* easily draw three-dimensional planes in Processing, just by adding a third, z-coordinate argument to the vertex function when using beginShape, which pretty much made all the work I did on the trigonometric version obsolete, since this way you didn't have the rounding cracks, worked faster, and was about a billion times easier to code.
One thing I never managed to figure out how to do, that I really wanted, was to have the camera bob up and down according to the elevation of the pixel beneath it, so as to give the impression of actually walking over the fingerprint landscape rather than just the camera hovering over it. There's no easy way to do this since the push and pop methods used to perform the camera movements alter the origin, which means there's no easy correlation to where the camera is in relation to the image pixels.
I'm pretty sure the way to do this is to just track the location of the camera in a couple of variables that get modified whenever camera transformations are performed, and then you just use an equation to figure out where the end camera position ends up on the coordinate grid, dividing by the size of the drawn pixels to compensate for the scale change: x = distance traveled * sin(angle changed) and y = distance traveled * cos(angle changed).
I haven't managed to get this to work right, yet. Maybe I'm compensating for something wrong somewhere. Or maybe there's soemthing wrong with my original camera transformations, which is why it doesn't correlate. I'm convinced there's still something wrong with the camera rotation. It doesn't seem like the pivot is always quite where it's supposed to be, which is directly under the camera location.
It would also be useful to know the camera location in relation to the image array in terms of improving performance. I'd be able to just draw the pixels directly in front of the camera, instead of always rendering the whole landscape all at once, even if you don't see most of it.
Mapping Project Applets:
the trigonometric version - high resolution
the box function version
the beginShape version - low resolution, better performance
No comments:
Post a Comment