Sun, 30 Sep 2007

Tippytoes into OpenGL

Posted by fluxe at 6:09 PM in /

 

I can assure you that this software is not going to end up looking like your average two hundred person-year game with its artistic teams and software teams. That being said, you never know what it might turn out looking like, because there are two ways that I might be able to adopt a sophisticated graphical front-end: Breve and Digital Space are kind of fellow-projects with this one related to www.biota.org and in the biota podcast series there has been some talk about collaboration.

It would be a real kick to introduce the graceful fluidity of tensegrity to those environments, and that might inspire future engineers to look into building things using tensegrity. At the very least it should be considered as a structural principle very useful in zero-gravity. I imagine the rotating wheel shape from 2001 A Space Odyessey but then not as a solid donut but rather as a vastly larger donut-shaped tensegrity where people live in the bars. Maybe there would even be bars that were bars that you could frequent.

For now, I'm impatient to have something to look at, and I want an animated view that performs at a really high rate of speed so the first thing to build will be a rendering based on lines instead of polygons. It's important not to forget that the most exciting thing that will happen with this software will be the evolution process, and that occurs out of anybody's view because observing the movement slows it down by orders of magnitude. When you view it, it should be possible to really make the movement fluid with a large frame rate.

Something I should mention: I had a text chat with Rui Alao last night, an internet friend and podcast listener from Brazil, who recently presented Darwin at Home at an academic conference, it seems. It was more about the concept than about the techniques, he said. I hope to hear more from him about it and that he puts the presentation online, even if it is in Portuguese.

The GL code is of course built on the basis of the Visitor idea from last episode, and the visitors required will be looking at the bars and cables and painting lines on the screen. This part of the code is really another refinement of what I've used in previous versions of Fluidiom, and not something I'm doing for the first time. The nice thing about that is by now I really kind of know how it all fits together so I can explain it with some more confidence.

Almost forgot! The graphical version is available using Java Web Start from http://www.darwinathome.org/tensegrity-20070930/


Have Fun!

Technorati Tags:

Sat, 29 Sep 2007

Physics Feedback, Visitors, and Graphics Soon

Posted by fluxe at 12:06 PM in Code

 

Some interesting feedback came in since last time, both about the physics ideas that I talked about last time.

Sven Heinz was concerned that the behavior when one end of a bar goes underground due to gravity the rotation is being cancelled out. Also he thinks that slack should exist and that evolution should be able to eliminate it by natural selection. I suppose he's right about the rotation, although he doesn't really suggest a solution. The second point remains to be seen, but I'd like to find out what works by trying it out. Later we can try a number of things.

I think it might be interesting to have the floor be not so absolute at Z=0, but rather to make it kind of cushion, becoming more "arresting" the deeper you go, perhaps quite extremely, but not the absolute above-below difference we have now.

Some other very nice encouraging email from Matt Dick, who enjoys the podcast and suggests that overstretched cables could just "blow up". The way it is right now is they throw a StretchException, and the consequences of that is something that has to be built. We could delete the stretched cable, or lengthen it, or anything else. To be determined. It could even be used as an anti-fitness factor rather than something as absolute as deletion. Matt is also pleased with the quadratic drag, and seems to also think in terms of a viscosity idea in the floor rather than absolute Z<0 behavior.

Anyway, the main focus of this podcast is the things that have to be added to the code getting ready for visualizing things with OpenGL, using JOGL. Certain coding design patterns are a lovely sight to behold when they appear to be in their native habitat, and the one that I will introduce now is the Visitor which will allow the nucleus of the "Tensegrity" class stay intact and not grow more complex while any number of visitors pass through the tensegrity, from simple ones to very tricky ones, to do their magic.

Here's the sound to go with the text and the code. Stay tuned, because next time we will see something graphical for the first time!

Technorati Tags:

Sat, 22 Sep 2007

Cable Physics: Ideal Elastics, Testing for Catastrophe

Posted by fluxe at 4:12 PM in /

 

This podcast episode is about completing the Physics class by adding cable physics to complement the bar physics that I had already built. It may well sound a bit chaotic because the process is much like stumbling blind through a forest, and while developing I bumped my head a number of times.

We're still in the deferment-of-gratification stage of the project because there are no flashy graphics to play with. Instead I'm just trying to get a handle on the numbers and the most basic principles I need. Everything is happening in the TestTensegrity class (see below). The interesting part is that the test is now cranking up the tension until a catastrophe occurs.

Last time we explored rigid bar physics, but this time the cables have to be defined. I started with cables that has a given (desired) span value but then the cables can be "slack" (when they're shorter than they want to be) and that introduces issues I would like to avoid. So I broke new ground again by making the cables have a desired span of zero by-definition. This way they really only can pull.

To do these tests, first the Factory class had to be expanded to create tensegrities that contained cables. There are two so far: a cross (two bars with four cables around, like a kite, diamond shaped) and a 3D cross (three bars perpendicular to each other with an "octahedron of tension" around them, like the X-Y-Z axis).

The Physics class is now furnished with a couple parameters to determine how it behaves: gravity and tension. Gravity is simple, just a pull downward, and during this phase the gravity has been switched off (in the tests). The value we are interested in is tension, which is multipled by the actual length of the cable to determine the force applied to the movement arrows of the joints at the end of cables. When the cable exceeds a given length, a StretchException is thrown!

Also, a new addition is the idea of quadratic drag. In the past I have always used linear drag resembling slow movement through a fluid, but quadratic drag resembles rapid movement through a fluid. The difference is that now the brakes are pushed a lot harder when the joint is travelling fast. Imagine pushing your hand through water.. the harder you push the more it brakes.

I hope you enjoy the audio.

Technorati Tags:

Wed, 19 Sep 2007

The Tricky Physics of Rigid Bars, Developing the Arrow Class

Posted by fluxe at 10:31 PM in Code

 

In this podcast i get a start on the Physics class which will be responsible for acting on a tensegrity to make it move and jiggle in a realistic way. This is where tensegrity gives me a wakeup call because i discover that there were some things wrong with the very first steps i took in the previous episode.

The key is that in previous projects i've always created intervals and joints because all intervals were springy, but now with tensegrity i'm making the bold assumption that there are bars and cables, and that the bars are completely rigid. Also bars never connect to each other so a bar can be the full owner of the two joints at its ends.

While writing the Physics class i found myself looping twice through the intervals, first touching the ones that were cables (bar==false) and then touching the ones that were bars (bar==true). That smelled funny. Meanwhile, however, writing the Physics class has required that i start giving Arrow some of its needed functions.

I ended up splitting the Interval class up by making it abstract and creating two concrete subclasses called Bar and Cable, each with its own personality. Bars, for example, create their two joints when they are created, and the joints are dedicated to their bar. Cables connect existing joints (which are bar-ends). Now the smell is gone because a tensegrity contains bars and cables, exactly as it should be, and the Physics class can just walk through the cables, and then through the bars, doing it's work.

The difficult part of this is the explanation of how the physics of bars is programmed, but this is a very important hurdle to jump before we really get going. You'll have to listen to the podcast for the full story.

Technorati Tags:

Sat, 8 Sep 2007

Tensegrity Evolution from Scratch

Posted by fluxe at 4:48 PM in Code

 

This is a reboot podcast. I've decided to put an end to my Analysis Paralysis and start completely from scratch and take listeners along for the ride from the very first classes, and the very first principles, to a fun-to-use environment in which tensegrities evolve.

You can access the code for this podcast using Subversion with this command:

svn co https://fluidiom.svn.sourceforge.net/svnroot/fluidiom/tensegrity -r 617

These are the classes that we start with:

Listen to the podcast here. Enjoy, and stay tuned!

Please contact me if you feel even the slightest bit inclined to comment, even if you just say hello, because a bit of feedback goes a long way to motivating me. geralddejong@gmail.com

Technorati Tags: