A Little Break

Last week we went to Big Cedar in the Ozarks for a little break. No computer work at all. OK I did sneak a quick look at e-mail but that is it. I did take lots of pictures and will get them posted on my flickr stream this week. Since I just had my macro lens took lots of flower pictures. Here are a few shots:



This is a male carpenter bee, Xylocopa virginica. This is a macro uncropped so you can see maybe just how close he was to my lens!



We timed this vacation to coincide with the Dogwood bloom. Maybe we were a week late for the best viewing but the trees were still quite nice!



Most people might think I took this shot for the bee. Actually, no. I had never seen ornamental cabbage when it bolts, or at least had never paid attention to it. But the yellow blossoms against the purple stems are quite striking making me reassess my dislike of ornamental cabbage.

Today I had meetings at school and spent sometime designing a chromosome activity. More on that later this week.

Evolution IV

Now that I have my drift and selection modules in hand, the next goal is to working on activities that can be fit around them. I know this is a bit backwards on the surface, but what I want to focus on in my evolution module is mainly the agents of evolution. These are basically:

• Mutation
• Genetic Drift
• Non random mating (of which there are several types!)
• Migration
• Selection

To house the activities related to these agents, I have deviated from my photosynthesis and genetics design and come up with a series of open activity arenas. Each one will have a sensor driven script for tracking visitors, an simple activity rezzer of my own design, built into one of the corner posts. Rather than use my Carmine land, I am building the agents of evolution site at my College's island. The design challenge is to work with in a 281 prim limit.

The natural selection and drift modules use temporary prims so only the rezzers for these count. My 5 activity arenas and office take up a grand total of 67 prims so that leaves me a budget of 220 prims. Now I can stretch that, since activities will not be rezzed all at the same time since each arena but each activity has a "budget" of 40 prims. Ah but each activity arena can hold multiple activities in waiting so the "budget" isn't so draconian after all. 220/5 activity arenas.

Oh and my goal is to have this done by May 7th. At least now I can focus on design more rather than the arcanity of the LSL's llfrand function and other such issues. Plus I will have two radically different design approaches to compare, the module in a box approach of my photosynthesis and gentics builds versus my more open arena centered approach.





Evolution lends itself to the more open approach, and this summer I will install photosynthesis and the Cami genetics modules in Carmine using the arena centered approach. That way I can have the same material side by side with different design features to begin to assess what works best with students.

Evolution III: the Predator version...

My natural selection module works pretty well but one concern was how to make it a bit more interesting. One obviously way to do that would be to make Cami's that move so that they are harder to spot and catch.

So since I really don't know a whole lot about making things move in Second Life, the first thing I did was develop a cami that will roam around randomly but stay in my land.

The strategy I developed builds on a function I had previously scripted for random movement of a prim:
//--------------------------------
vector newcoodinates(vector pos ,float pathlength, integer start)
{

integer icount;
float deltax;
float deltay;
vector temp;
float ground;
temp = llGetPos();
if (start = TRUE)
{
deltax = llFrand(pathlength)-pathlength/2;
deltay = llFrand(pathlength)-pathlength/2;
temp.x = temp.x + deltax;
temp.y = temp.y + deltay;
ground = llGround(<0.0,0.0,0.1>);

temp.z = ground;
if (llGetLandOwnerAt(temp) == llGetOwnerKey(llGetKey()))
{

return temp;
}
else {

return pos;
}
}

return temp;
}
//---------------------------------------------------

The idea is to take the prim's current position and update it with a "random" number between zero and some maximum path length. That's what this statement does in the one dimension:

deltax = llFrand(pathlength)-pathlength/2;

Since I want the cami's to hug the ground for the vertical dimension I use LSL's llGround function:

ground = llGround(<0.0,0.0,0.1>); the result is the vertical dimension.


One thing that flummoxed me for awhile was how to keep the cami in bounds. My original idea was to have the cami detect when it was on someone else's land and have it turn around and leave. But that turned out to be more difficult to script in a totally fool proof manner to this trigonometrically challenged scriptor. Besides, it seemed much better and nicer, to stop the cami from even entering someone's land in the first place:





So that's what this piece of code does:

if (llGetLandOwnerAt(temp) == llGetOwnerKey(llGetKey()))
{

return temp;
}
else {

return pos;
}

The rest of the basic movement script is deceptively simple:

default
{

state_entry()
{

do {

newpos = newcoodinates(llGetPos() ,2,start);
llSetRot(llEuler2Rot(<0,0,-pi/2>)*llGetRot());
llLookAt(newpos,1,0);
llSetPos(newpos);


llStopLookAt();


}
while (start==TRUE);

}
}

The rotation functions are sort of trial and error on my part but the cami's end up with an interesting waddling motion, so I am pleased with that even if it wasn't quite what I wanted at first.

Deceptively simple because I also needed toggle that stops the cami's so I can catch them and for determining the cami genotypes and phenotypes. Fortunately my previous cami scripts are easily modified to to work with my cami movement script.

The result is Natural Selection the Predator version right now at:

http://slurl.com/secondlife/Carmine/123/151/135

Just touch the light blue prim and 50 maddingly difficult to catch cami's will start swarming around:















The idea is to put yourself in the role of a predator selecting against one of the phenotypes. The phenotypes use my cami genetics scripts and it is possible to select against one of the phenotypes and eliminate the genes for that phenotype, but its harder than it looks.

This version will allow you to keep selecting until the the cami's derez at which point you must touch the blue prim again to rez the next generation of cami's using the ones you didn't get as the parent population. I may change this feature.

The main script in the cube again handles all the book keeping and generates a report tracking the allele frquencies when you touch it to rez the next generation.

By the way, when you touch one of the camis in your role as predators they explode red blood thanks to a little particle script...next will be sound effects.

So even if you don't know squat about population genetics or evolution, at least you get to blow up stuff. I guess there is a bit of adolescent even in the most prim and proper of us.

Oh if you visit, watch out for cami sharks.




















This week I will be designing some suggested activities related to evolution using my cami system and also taking a few days for a trip to the Ozarks for springtime dogwood viewing, I hope.

Evolution II 101 Dalmations?

Well no, how about 30 Caminalcules after selection favoring a recessive allele for 8 generations. The natural selection module beta is finished and works very well. The basic strategy is to have the user or users act as visual predators removing camis from the population. The module might for instance be on a certain background where some cami phenotypes are real obvious while others are not.

The "predators" remove cami's by touching them, and the population is up dated. After a set period of time say 1 minute the remaining cami's are used to make a new population, which the module generates when it is touched and the cycle is repeated until only one genotype remains or until the users give up.

At the start of each generation the module generates a report in chat on the screen showing the allele frequencies for both of the cami loci.

If Cami's are never "eaten" the result is genetic drift. So this module really combines genetic drift and natural selection. It does not use or even compute selection coefficients, but one could add that to a report.

A Scripting Interlude

While revisiting my genetic drift module and starting my natural selection module, I decided to fix a potentially annoying problem. Since Caminalcules rez as physical objects sometimes they behave really flaky and end up in other regions. Right now they are set to die on their own after a set time but that would be a scant comfort to another land owner who has one of these things appear on her land.

With the help of the good folks in the College of Scripting Music Science group here's the basic strategy...

default {
state_entry()
{
llSetTimerEvent(1.0);
}
timer()
{
// check if the touching person is over the script owner's land

if (llOverMyLand(llGetKey())) {
llSay(0, "the prim is on my land.");
} else {
llSay(0, "the prim is NOT on my land.");
llDie();
}
}
}

Not real hard and experienced scripters probably know about llOverMyLand, but it solves one of life's little mysteries. I can of course shorten this to a single if statement if I just want the critter to die, but I might want different sorts of behavior depending where the critter is, hmmmmm.

By the way, since I have several parcels, I was interested to find that llOverMyLand doesn't care what parcel the object is in just whether or not you own the parcel.

Soror Nishi's at it again...

I am a big fan of Soror Nishi's phantasmagorical plants and was thrilled to see that she has lots of new stuff on her site. Some of her things are pretty prim intensive and much of my stuff is the same way. So prims are precious. But I do believe in supporting artists I like to the degree that I can so did find a couple things that were low prim.

Here is one of my two buys sited in my land.



Camilab is in the background.

You can visit Soror at http://slurl.com/secondlife/Lifstaen/10/50/228

Definitely worth it.

Also today, actually yesterday now I spent some time in the Costa Rica sims poking around. These are definitely worth a visit as they are very detailed.

Here is a view from the Palo Verde sim:



By the way the Costa Rica builds are so nice that for the first time I have been tempted to buy into a private region...but its quite a bit more expensive than my mainland region.

I recommend Cocos Island which you can visit here:
http://slurl.com/secondlife/Cocos%20Island/128/218/1002

Here are a couple of pictures:



This bridge is quite famous in RL.



An example of the wonderful plant texturing on Cocos Island.

A certain cell membrane...

My biology viewers might recognise what this SL model is supposed to be.



This is a preliminary prototype for a neuron membrane showing stylised transport proteins (purple). The round guys with the lids are gated sodium proteins the lidless tubes are gated potassium channel proteins. The "lids" on the sodium gates will be scripted to pop open to let Na+ ions through while the bottoms of the K+ channels will flip open and closed.

The oval shaped guy on the right is part of a Na+/K+ pump.

All these proteins are embedded in a stylised plasma membrane (red fatty acid residues connected to white polar heads with phosphorus for the phospholipids).

This project is actually part of a planned metabolism build which uses the neuron to illustrate how cells use active and passive transport for complex processes. So it's not meant as a full action potential simulation though my scripting strategy will take that possibility into account.

Fret no more!

When at the Best Practices conference several presenters beefed about having to face the slide viewers in use to advance their slides.

Well, heated discussions of the merits of slide presentations in SL aside, I modified my simple viewer discussed in my last post to take care of this problem. So fret no more SL conference presenters because now there is Simone's absurdly simple minimalist podium slide viewer/podium! (AKA Silly viewer)

It consists of a big viewer for the audience and a small viewer that the present er can use to control the slides while facing the audience! All you do is transfer your slide textures from you inventory to the inventory of both the big and small viwers and you are good to go.

I haven't tested it on big sets of slides so I don't know how Erich Bremer'sbuffering system will work with big sets. But it took about 5 minutes last night to whip this together (with a last minute change tonight). By the way I did not start out to make this viewer but it was a proof of concept to myself of another project, namely to update my clunky image map type viewer used in my photosynthesis build. More later.

The picture shows my male AV, Simeon Gateaux who has his own land next to mine and he tests permissions etc.

So if you think my silly little viewer might be of use to you (you can resize and move both prims), you can IM me, Simone Gateaux, in SL or stop by my garden spot (SLurl) in Carmine and grab a copy to try and a note card. It's free but both feedback and donations toward my private tier are accepted.

All you have to do (and this is changed from my desription in SLED BTW, is rez the viewer and insert your slides in the right order (careful here SL will put them in alpha order) into the "podium", resize the main viewer, position the podium and you are ready. Do not mess with the blacked out parts of the prims. They hide the buffered textures.

The Cami Lab is up!

The Caminalcules (camis for short) have been safely installed in a Mendelian Genetics lab module called the Cami Lab. I use my note card configurable camis to illustrate dominance relations, monohybrid crosses, and dihybrid crosses. The evolution module will be directly underneath.

I have had to readjust my land and merge several parcels to give me some prim breathing room. Feel free to come and visit Cami Lab currently at:

http://slurl.com/secondlife/Carmine/128/144/136

As part of this, I rescripted my simple viewer to use Erich Bremer's double buffering script which makes loading much faster. My essentially new viewer uses LSL's way cool llDetectedTouchST function. This function detects where on a prim's surface you are touching and returns that as the x and y terms of a vector.

You can then access, these to do things like change a slide or teleport. What is really cool is that the coordinates are normalized to the size of the prim so they are presented as a float between 0.0 and 1.0, so if you stretch, say a viewer, the detected function still works properly.

Evolution I: Simulating genetic drift with Caminalcules

So far I been working with my caminalcules in terms of genetics. But of course-and maybe someone ought to tell creationists about this-evolution and genetics are logically connected and evolution follows from genetics. So naturally I want to use my system to simulate the basic mechanisms of evolution.

Yesterday and today I programed a prototype Evolver (pink square) that simulates genetic drift. Genetic drift is an agent of evolution where a population's genetic make up changes due to sampling error. Drift is particularly important for small populations, such as caminalcule populations which given the prim limits in SL can never be very big.

Genetic drift is actually easier to simulate than natural selection, so it makes a good starting point for scripting and probably also for students to play with.

To look at populations of caminalcules I treat the population as a list containing the genotypes of all the individuals in the population. I use the same phenotype routines developed for genetics crosses and simply can access the approriate caminalcule through the list index.

Next I had to write a series of population functions:

string randommating(list the_pop) chooses two individuals from the population at random to mate and produces one offspring.

initialise(integer popsize) produces an initial random population and stores it in a list called start_pop_list and returns that list after rezzing an offspring:

Here's a snippet form this function:

start_pop_list = start_pop_list + genotype;
pass2offspring = (integer)genotype;
llRezObject("bigpup",llGetPos()+<2.0-llfrand(4),2.0-llfrand(4),0>,<0,0,0>,<0,pi/4,0,0>, pass2offspring);
}
while (++icount
return start_pop_list;

Most of the other routines are functions made before for the Caminalcule genetics module. So there is nothing new here. The simulation is direct in that I do not calculate allele frequencies and sample from that.

Doing random mating is pretty easy and here is the new function that handles that:

string randommating(list the_pop)
{
integer index;
string organism1;
string organism2;
string thezygote;
string gamete1;
string gamete2;
integer pop_size = llGetListLength(the_pop);
index = irandom(0, pop_size-1);
organism1 = llList2String(the_pop,index);
gamete1 = make_a_gamete(organism1);
index = irandom(0, pop_size-1);
organism2 = llList2String(the_pop,index);
gamete2 = make_a_gamete(organism2);

//----pick 2 organisms at random to mate from the_pop, self mating allowed----
//list the_pop must have been checked!


return make_zygote_string("4",gamete1, gamete2);
//4 because we assume independence here
}


Well so what happens with genetic drift? I want to write routines to quantitatively track what happens, but for many situations running the drift script for for a number of trials ought to get the idea across so here are some pictures from two sets of runs.

My first run started with a population that looked like this:


Four generations later...

Notice the pink and green phenotypes are becoming more common. The the genes related to the white caminalcules have apparently been eliminated. Since the genes related to the white photype are recessive the student might think (as did some geneticicts in the early 20th century) that the recessive allele ought to dissappear over time any way.

By the 11th generation all you have are these caminalcules:

Actually the picture shows the population after 14 generations since I wanted to make sure the other types were eliminated. This nicely shows that the effect of genetic drift is to reduce genetic variation in a population.

Now consider a trial starting with this population:

Not very different than the starting population from the previous run. But look what happens now! This is at generation 10. Note the large number of white caminalcules. Remember white is recessive.



And by generation 15:


Only the white caminacules are left and it looks like only one type of spotting! This illustrates two points. First of all as I noted earler, recessive alleles are not eliminated just because they are recessive, but evolution is strongly contingent. Just because you get one result one time, the chance elements in evolution such as genetic drift may cause completely different out comes the following time. This can lead students and teachers into all sorts of interesting avenues of thinking about how evolution works!

If you want to see how this works, look for me in world.

Hopefully later this week I will have worked through natural selection.