Welcome back to me!

It has been a very long time since I made a post to this blog. The reasons are many and varied - among them, that I had little to post about that wasn't some sort of whining or bitching or other negativity. As most of the reasons for this state of affairs were more personal than related to OpenSim or OSGrid, I felt it better that I remain silent than reflect personal issues on either of these splendid efforts.

Indeed, I have been considering passing the blog off to someone else, in the interest of keeping the name in good, productive hands.

That said, I've changed my mind. I do have something to post about after all, that is positive, usefull, and perhaps even potentially usefull to others! YAY!

So, without further ado, I'll make this new post, and hopefully many more to come, on the topic of the Git source control management system.

First, a little bit about why this topic comes to light at this time.

Recently, much to the dismay of many users (and not a few developers), OpenSim transitioned from the Subversion SCM to the Git SCM. Without getting too deeply into history, Linus Torvalds, originator of the Linux Operating System project, wrote git in an effort to make a better source control system, flexible enough to accomodate the needs of the many thousands of people submitting patches to the linux kernel, and to make his (or others, as the case may be), lives easier with respect to managing these many patch submissions when merging these patches. As with just about everything Linus does, he pushed the tool to the limits of software technology, and produced entirely new functionalities not previously seen in any SCM, that specifically target organic software developement processes within volunteer communities of open source developers.

Whew! good thing I didn't get too deep into history!

So, essentially, until it's a non-issue, have a look here each or every other day or so, for a 'Git Trick of the Day'. And with that, here's todays Git Trick of the Day, presented as a problem coupled with a solution to that problem (I'll try to stick to that format as I accumulate posts):

Problem:

The local git repository, obtained via the 'git clone' operation, contains much more than just the source tree for the project. It also contains a good number of git SCM artifacts, which represent the entire revision history of the project to the time of the clone. This makes it less than optimal as an environment for building and testing the code that resides in the project.

While this might seem an incredible handicap, it is in fact one of the chief sources of power that comes with git.

I dont want to get too far from the problem space I'm addressing here today, so I wont get into a discussion of those intricasies at this point - rather, I will provide a command for extraction of the source tree into a working directory apropos the build+test operation.

Without further ado, here's that command:
git tar-tree HEAD opensimstaging | (cd ~ && tar xf -)

Now, lets disect that a bit. But first, a little warning is in order: Git is still very much in developement, and change is the order of the day - you will need the latest stable revision to use this command (1.6.0.2 at the time of this writing). Further, I'm a linux user primarily, and I have not yet vetted this procedure on windows - though I will, in the near future, and in the not-too-distant future I will advise in a comment to this post as to how to accomplish this on that 'other' platform ;)

One last warning with respect to the changing nature of git: this command, even on this late stable revision of the code, is already deprecated! Dont let that concern you though - git is pretty smart, and will 're-write' the command for you to produce one that is more current. I'll add that to comments as well, once I've puzzled it out.

Onward!

The git command above does the following things:

Firstly, it executes the git command:
git tar-tree HEAD opensimstaging

What this does is extract an archive ready copy of the repository 'payload' from the HEAD - also referred to as the 'master' branch. This is the default branch of the repository, chronologically current as of the time the git clone command was used to instantiate a local 'fork' or working copy of the repository. It bases this tree in the relative directory 'opensimstaging'. You can feel free to replace 'opensimstaging' in this command with a directory name more appropriate to your local needs.

As the output being produced is in 'tar' (tape archive) format, this is the directory the tree will be unpacked to (were it actually being written to a tar file. Tar files are an associated topic, but a bit out of scope for this post). Suffice it to say, that this tar format file will be written to a special unix file called 'stdout'. This is also known as 'the console' - in other words, where things get printed.

This is where the rest of the command comes into play:
| (cd ~ && tar xf -)

Note the first character, the pipe '|' symbol. In unix parlance, this is the command's 'plumbing'. It literally ties the output from one command to the input of another, in this case a tar command.

Note the presence of the parentheses, the 'cd' command, and the double ampersand (&&). This construct has the following effects - the parenthesis binds commands together, and enforces the order of execution within them - think of it as a sort of aggregation of the commands within the parentheses, causing the shell to interpret them as if they were a single command. The double ampersands concatenate the commands adjacent to it such that the latter does not execute unless the former is successful. It's a sort of error-condition control. If the path requested in the 'cd' command does not exist, causing an error condition and failure of that command as a result, the subsequent 'tar' command will not be launched.

Barring any trouble, the sequence is like this: the tar formatted output from the git command will be passed to the tar command joined on the line by the pipe, but only if the encapsulated cd command works. Tar then unpacks the tar archive on git's output stream into the directory specified. Nifty, huh! and the product produced in the target directory is without the git-related objects that make up the repository proper, leaving it 'clean' for purposes of building and testing.

A further benefit is that the 'git pull' command can be used on the original clone to update it, and the process described herein repeated to produce an up-to-date build+test environment, without the overhead of cloning the project a second time from 'origin'.

I've tried to be both brief and thorough here, and I hope I've not added to your confusion - if you have questions, feel free to ask them in comments, or catch me on FreeNode IRC on #osgrid - I'm Hiro_Protagonist both there and on OSGrid.

Thanks for reading, and I hope I have been able to help you feel more comfortable with git!

Cheers
James

Hello, world!

I am on the intarweb!

TERAVUS OUSLEY FTW!!!!!!!!!11 uno

Teravus Ousley, among many other things, is the Open Dynamics Engine physics engine guru for the OpenSim project. Teravus, who is a proficient and prolific c# programmer, committed work on the evening of Dec 6 (or thereabouts) that fixed physical linkset and linkset collision issues.

This is a matter of some significance, and the importance of this work from a simulation science standpoint cannot be overstated.

Thanks Teravus, and Kudos!

W00Tz!!!

Building Rexx Viewer on Linux

First off, the source is BIG. Weighing in at 20MB, it's a hefty download.

Having just unzipped it, I am surprised to see no README or INSTALL in the archive root. This is not especially encouraging. What is there are four directories: avatargenerator, maxscriptexport, rexmeshtool, and rexviewer.

With the complete dearth of any sort of build instructions, I am left with no choices but educated guesses - I rather suspect that avatargenerator and maxscriptexporter are utilities, and so I will begin with what might be the one included dependency, rexmeshtool. Here goes Norton!

Ok, so the rexmeshtool directory would appear to contain some sort of microsoft project. My guess is, there is no nant build configuration in the .sln file. Let's go see :D

Well, that didnt go far LOL

No nant .build file - this is essentially a microsoft-only project, and without a bit more work from the it's devs, it simply isnt going anywhere on linux.

I'd love to yell long and loud about the many things I had to do to get this to build - but unfortunately, that isnt going to happen.

So what I will yell long and loud about is this: This project is in NO WAY ready for building on linux. It may be a few short steps from it - it may be light years from it.

But without at least a prebuild file to gen a nant config to bootstrap the build process, it just isnt going to happen.

I will be keeping my eye on this, and on the Rexx guys - but they have a bit more work to do if they truly want to see this run on a linux desktop. Keep an eye on this blog for news relating to progress along these lines.

Cheers for now :)
Hiro P
OSGrid

Physical Vehicles Update

**** Physical Vehicles Update ****

The short story is, we have a few now :D

Thanks to one Owen Oyen of SecondLife and OSGrid :)

One day last month, Owen showed up at my deltazone region to discuss physical vehicles. Owen makes some rather specialized content in SL - he is the one who brought us the pitching of boats under sail, tidal currents based on an analysis of sailing grounds, and a host of other good things related to virtual sailing in SL.

Owen's concern that day we met was why exactly there were no physical vehicle functions implemented yet in opensim. After a brief bit of discussion, we came to the conclusion that the llVehicle class of functions in LSL are really a dramatically simplified approximation of a linear motor with some twists thrown in - literally - for rotating a vehicle about it's axis of travel.

As proof of our sound thinking, Owen produced in collaboration with myself, a very satisfying and functional virtual sailboat :) recently, Owen and Bri Hasp have extended this further, producing an iceboat as well :D

Both are available at or near the south edge of Bri's 'Baya' sim on OSGrid. Unfortunately, Owen has chosen not to make the scripts open - leaving it to me to apply what I learned with him in the production of such scripts.

While I have not yet produced these scritps (I got a job shortly after Owen released his freebie-but-no-copy boat), I will do so in the future - and, I will happily share with you the basics of the implementation.

First, llSetForce and llApplyImpulse are used as motors, depending on the need and circumstance. Owen, I think, finally settled on the use of llSetForce exclusively, but for reasons that were a bit obscure to me. Second, to prevent the vehicle from accumulating energy on an exponential curve, llGetMass is used to calculate a bit of friction, which takes the form of a force applied in a direction opposite to the direction of motion, in the same timer-driven calculation that applies the force which keeps the boat moving.

Finally, a wind source and sail position/forces are calculated and applied. Coupled with some stabilization and correction of movement through the periodic re-inititalization of axes outside that along which movement occurs with constants (usually zero), we have a boat that is readily pushed about the sim on Owen's 'wizard wind', which he has scripted into the boat as well.

Maybe that reads like greek to you - if so, go pick up one of Owen's freebies at Baya and just go have fun with it. Be sure to read the included notecards, because this vehicle has peculiarities and quirks uniquely associated with opensim. If not, I heartily ecourage you to take up this ground-breaking work and see what sorts of vehicles you can produce.

Off to attempt to build Rexx viewer source on linux :D

Cheers for now :D

WISH MEH LUCK!
and see the following post, wherein I describe my rexx-viewer-on-linux-viewer-building experiences.

Hiro
OSGrid

Scripted Physical Vehicles in OpenSim

First, to establish a bit of context on this report, I am referring to any vehicle that moves under the influence of the physics simulation. This specifically excludes llSetPos and like techniques.

While my experiments did not involve e.g., llSetVehicleType, they are still physical vehicles too - and dont worry, we'll examine the status of llSetVehicleType and friends while we're at it.

The first trouble I encountered in attempting to make a physical vehicle in OpenSim, is that there are no llVehicle* style functions implemented in the script engine. Or are there? a casual glance at the source code (if there is such a thing) would lead one to believe so. A closer investigation, though, will show that while the 'Not Implemented' stubs have been replaced with meaningful code that passes values up to the wooly innards of OpenSim, the afore-mentioned innards don't actually pass it on to the physics engine. But just about everything is in place to do so.

Why hasn't this last step been done? The answer to that is a bit complicated.

The short story is, the wooly innards are about to get rearranged, hopefully into a somewhat less wooly form. And as this is where all that physical script plumbing empties out, it's arrangement has considerable bearing on how llSetVehicle and friends are implemented.

Hold that thought while we take a stress breaker :)

What I *have* had at least some moderate success with is making a flying prim that is a physical vehicle. I know, but it's a start. How can this be done? Why, with llApplyImpulse and llTargetOmega.

Ok, it's an utter kludge LOL but it works.

Why llTargetOmega? it's the only LSL function currently implemented that can physically rotate a prim. llApplyImpulse provides both the lift and the forward thrust. I use the standard vehicle 'control' event to obtain the users inputs via 'llTakeControls', and I use llTargetOmega to stop and start a rotation of the prim when the appropriate keys are pressed to turn left and right.

Why dont I post that script here and now? It's just too ugly. When I spend a bit more time with it, I *might* actually have a reasonably manueverable flying prim - but as it is now, it's just barely proof-of-concept.

Now, stressbreaker is over!

Basically, the work on the OpenSim 'wooly innards' I referred to above is highly complex, represents a huge change to the core codebase, and must be worked over and discussed by at minimum 10 different software engineers. It's going to take a bit of time, I'm afraid. Be patient, it'll be worth the wait.

In the interim, I hope to properly implement llSetRotaionalImpulse and llSetRotationalVelocity, both of which bear enough resemblance to llTargetOmega that I should be able use it as a reference in the source code; if I am successfull, this should give us sufficient tools to implement some very useable vehicles based on llSetForce and llApplyImpulse.

Crude, I know. But better than a foot-race :)

Cheers for now!

KUDOS!!

Kudos to JHurliman of the libomv project and Teravus Ousley of the OpenSim project for their highly successful efforts this weekend!

JHurliman and friends have recently finished up some fairly major work on libomv, and Teravus worked closely with him on the one hand, and with the opensim/osgrid user community on the other, to bring this fresh new libomv into our OpenSim project.

The technical hurdles were numerous and sometimes quite high, but these fellows were definitely up to the task and it looks as if all the real show-stoppers and toe-stubbers have been addressed; things are cooking along quite nicely. :D

Cheers Guys! Great Job!