Programming

Und wie der Phönix aus der Asche…

Emerald ist tot, es lebe der Phoenix-Viewer! Das abgespaltene Emerald-Team um Jessica Lyon hat einen eigenen Fork vom alten Emerald unter dem Namen Phoenix Viewer gestartet.

Das Hauptziel des Emerald-Viewers ist die Weiterentwicklung der bereits vorhandenen Codebasis vom alten Emerald unter Einhaltung von hundertprozentiger Transparenz. Jeder Arbeitsschritt soll von außen kontrollierbar sein, es gibt bereits jetzt einen IRC-Channel der Entwickler, ein öffenliches Quellcoderepository, und und und… Zudem hat man bereits die Aufnahme im Third Party Viewer Directory beantragt und rechnet damit, dass dies eine rein Formsache sei, da keine historisch belasteten Entwickler mehr mit an Bord seien.

Unter den Entwicklern ist der bekannte LordGregGreg Back zurück und Kitty Barnett, von der die RLV(a)-Implementierung stammt. Auch ansonsten ist man personell sehr gut bestückt, man darf gespannt sein, welches Leben diesem Projekt in der Zukunft beschert sein wird, es liest sich wie all die guten Sachen von Emerald minus dem unnötigen Drama.

Hoffentlich haben die Entwickler dabei ihre Lektionen gelernt!

Emerald ist tot – lang lebe Emerald!

Der allseits beliebte alternative Second Life Viewer Emerald ist seit heute faktisch tot und die Entwicklermannschaft hat sich endgültig im Streit in zwei Teile aufgelöst.

Jessica Lyons schreibt in ihrem neuen Blog über die Gründe und Hintergründe: seit heute morgen haben nur noch Arabella Steadham und Lonely Bluebird Zugriff auf die Webserver und Webseite.

Die letzten zwei Forderungen von Seiten Linden Labs an die Entwickler, damit Emerald weiterhin als Viewer erlaubt bleibt, waren dabei folgende:

  • Emerald darf nicht mehr Emkdu und/oder LLkdu unterstützen, selbst wenn jemand per Hand diese Dateien in das Programmverzeichnis reinkopiert. Als Deadline dafür wurde der 3. September gesetzt und
  • es wurde verlange, dass Skills Hak, Discrete Dreamscape und Lonely Bluebird aus dem Entwicklerteam ausscheiden. Skills und Discrete kamen dieser Forderung nach, Lonely aber weigerte sich.

Die Folge, wenn die Entwickler dem nicht nachkämen, wäre das Blockieren des Zugriffs von Emerald auf das Second Life Grid und so wird es wohl bald geschehen. Da Lonely Bluebird den Zugriff auf die Entwicklungsserver für den Rest des Teams sperrte, können diese nicht mehr bis zur Deadline den Forderungen Linden Labs nachkommen.

Mehr noch, Fractured Crystal will Emerald als Warenzeichen eintragen lassen, so dass das bisherige Team nicht mehr den alten Namen gebrauchen kann.

Deshalb trat Jessica Lyon aus dem Emeraldprojekt aus. Die Entwickler um sie herum denken darüber nach, auf Basis des alten Emeralds ein neues Projekt zu starten, um dort weiter zu machen, wo Emerald nun aufgehört hat.

Auf der offiziellen Seite von Emerald wiederum schreibt Arabella Steadham, dass Linden Lab seine Forderungen dergestalt gestellt hätte, dass sie diesen einfach nicht nachkommen könnte. Während die Sache mit Llkdu und Emkdu machbar gewesen wäre, hätte die Forderung nach dem Ausscheiden der drei Hauptentwickler dem Projekt das Genick gebrochen.

Es wird keine weiteren Versionen nach heute mehr von Emerald geben. Die bisherigen Versionen werden noch solange funktionieren solange Linden Lab den Zugriff nicht ein für allemal blockiert.

Es wird eine letzte Version von Emerald heute geben, die all die Änderungen enthält, in denen se die letzten sechs Monate gearbeitet hätte. Es wäre eine Schande, wenn dies verloren ginge.

Mein Fazit: Emerald ist damit als Viewer endgültig tot, die Wahrscheinlichkeit eines Forks aber doch stark gegeben. Sollte dies tatsächlich um ein seriöser arbeitendes Entwicklerteam geschehen, dann hätte dieser Viewer gute Chancen Emerald zu beerben.

Imprudence Viewer Voice Howto auf Deutsch

Worum geht es?

Der alternative Second Life Viewer Imprudence kommt aus Lizenzgründen bis Version 1.3.0 RC1  nicht mit den benötigten Programmbibliotheken der Firma Vivox daher, die zum Betrieb von Voice in Second Life benötigt werden. Viele aber können und wollen auf Voice in SL nicht verzichten und es ist mit ein wenig Handarbeit möglich, mit Imprudence als Viewer auch Voice wie gehabt benutzen zu können.

Dieses Howto beschreibt deren nachträgliche Installation von Voice unter Windows, da der Installer von Imprudence diese Handgriffe bis zurVersion 1.3.0 RC1 nicht vornimmt; ab Version 1.3.0 RC2 ist das im Installer eingebaut!

Voraussetzungen

Zur Installation der Dateien wird ein Archiventpacker benötigt, der mit .tar.bz2 zurecht kommen kann. 7zip kann das, wer daher nicht sicher ist, bitte zuerst diese Freeware installieren, WinRAR kann es auch.

Und los geht es!

Imprudence ist installiert, 7zip oder ein Entpacker mit vergleichbarer Funktionalität ebenfalls? Gut! Als erstes müssen per Hand die Programmteile für Voice aus dem Internet heruntergeladen werden.

Für Imprudence 1.2.x lädt man sich diese Datei herunter und für Imprudence 1.3.x diese. Danach öffnet man die Datei mit dem Entpacker, bei 7zip braucht dies zweimal, da die Datei doppelt gepackt ist.

Im Verzeichnis indra/newview/vivox-runtime/i686-win32/ des Archives dann sind die benötigten Dateien. Aus diesem Ordner kopiert/extrahiert man die folgenden Dateien, und nur wirklich diese, in den Installationsordner von Imprudence:

  • ortp.dll
  • SLVoice.exe
  • vivoxsdk.dll
  • wrap_oal.dll

Dann startet man noch Voice in den Einstellungen neu, ein Relogin ist dazu unnötig und Imprudence sollte sich nun wie gewohnt mit Voice betreiben lassen. Herzlichen Glückwunsch!

Disclaimer

Für Fehler keine Gewähr sowie für durch Fehler und/oder durch Fehlbedienung entstandene Fehler keine Haftung. Diese Anleitung wurde nach bestem Wissen und Gewissen erstellt, aber auch hier gilt nach wie vor: Hirn einschalten und wenn man sich nicht sicher ist, was man tut, lieber die Finger davon lassen und sich jemanden holen, der sich damit auskennt.

Überdies: kein in world Support jedweder Art.

Llkdu, Emkdu und OpenJPEG oder: was ist was und wozu braucht man es?

In allen Diskussionen um den Emerald-Client wird auch immer wieder über die Emkdu.dll diskutiert, viele wissen nicht wirklich, wozu diese gebraucht wird noch was sich hinter diesen verschiedenen Begrifflichkeiten wie OpenJPEG und Llkdu verbirgt. Ich will hier einmal das Knäuel ein wenig aufdröseln.

Die Basis von allem: JPEG2000.

Second Life basiert auf 3D-Objekten, die mit Texturen beliebigen Inhalts überzogen werden können. Da diese Texturen viel Bandbreite bei der Übertragung und auf Seiten Linden Labs dauerhaft Speicherplatz benötigen, war beim Design von Second Life eines der Ziele gewesen, einen Standard zu wählen, der möglichst viel Information bei möglichst wenig Speicherbedarf abbilden kann.

Man kennt diese Problematik bereits aus dem WWW, dort ist JPEG das verbreitetste Kodierungsverfahren für Bilder aller Art. Wichtig dabei ist, dass JPEG Bilder verlustbehaftet komprimiert, das bedeutet, es gehen je nach Qualität mehr oder weniger gut sichtbar Informationen verloren. JPEG basiert dabei auf verschiedenen Kodierungsschritten, wobei das Herz ein aus der Mathematik bekanntes Verfahren namens diskrete Cosinus-Transformation darstellt

Nun entstand JPEG aber im Jahr 1992 und seitdem blieb die Welt nicht stehen, im Laufe der Zeit entstanden bessere Verfahren als dieses. Bei der Konzeptionierung von Second Life entschied man sich für JPEG2000 als den Standard aller Bilder. JPEG2000 ist jünger als JPEG, damit technisch weiter und komprimiert Bilder besser. JPEG2000 ist rechenintensiver im Vergleich zu JPEG und basiert auf dem Verfahren der diskreten Wavelet-Transformation, zudem ist es teilweise von Softwarepatenten geschützt.

Kurz: alle Bilder, die wir in Second Life sehen, basieren auf dem Bildstandard JPEG2000. Da dieser sich bisher bis auf einige Nischenbereiche kaum durchgesetzt hat, muss der Viewer die benötigten Grundfunktionen zum De- und Kodieren dieses Standards selber mitbringen. Dies geschieht mit Hilfe einer Programmbibliothek, die die dazu benötiigten Funktionen bereitstellt.

Auftritt: OpenJPEG!

OpenJPEG ist eine Opensource-Implementierung des JPEG2000-Standards, die unter der BSD-Lizenz steht. OpenJPEG ist dabei solide programmiert, aber was die Kodierungs- und Dekodierungsgeschwindigkeit anbelangt die langsamste Variante. Dafür ist die Benutzung von OpenJPEG kostenlos und damit ist es die Standardbibliothek aller alternativen Viewer, die diese zur Darstellung von Texturen benutzen. Der Vollständigkeit halber sei erwähnt, dass es mit JasPer noch eine weitere OSS-Implementierung des Standards gibt, die im Viewer aber nie Verwendung fand.

Schneller: LLkdu!

Die industriell genutzte Standardimplementierung in C++ von JPEG2000 stammt aus dem wenig bekannten Softwarehaus Kakadu Software. Der Autor ist dabei einer der Urheber dieses Standards. KDU im Dateinamen ist dabei nichts anderes als die Abkürzung für „Kakadu“ und LL steht für Linden Lab.

Diese Implementierung des JPEG2000-Standards ist dabei um Längen schneller arbeitend als OpenJPEG, dafür aber kein Opensource und zum Einsatz in Software ist eine saftige Lizenzgebühr fällig. Linden Lab liefert seinen Viewer standardmäßig mit Kakadu als Bibliothek aus, und das Ergebnis macht sich in spürbar schnelleren Ladezeiten der Texturen bemerkbar.

Noch schneller: Emkdu!

Einer der Entwickler von Emerald, Phox Modularsystems, lizenzierte bei Kakadu ebenfalls deren Bibliothek in einer neueren Variante als Linden Lab das tat und baute darum seine eigene Variante namens Emkdu.dll. Die Lizenz zur nicht kommerziellen Nutzung der Bibliothek kostet dabei im Jahr 250 US$, und es machte sich in einer nochmals leicht schnelleren Geschwindigkeit beim Laden der Texturen bemerkbar.

Er baute in die Bibliothek dann auch eine Funktion ein, die den Dateipfad samt Windows-Titel vom Emerald-Viewer in den Metadaten der Avatartextur versteckten, das ist inzwischen nicht mehr der Fall, aber war auch der Anstoß für viel Kritik.

Fazit

Emerald funktioniert bisher mit Emkdu, Llkdu und OpenJPEG, ansonsten jeder Viewer zumindest mit Llkdu oder OpenJPEG. Die Bibliotheken sind dabei beliebig austauschbar; wer z.B. im Verzeichnis von Emerald die emkdu.dll löscht und den Viewer neu startet, dann nutzt der die noch vorhandene openjpeg.dll und gut ist es.

Wer wirklich auf der sicheren Seite sein will, der sollte momentan nur OpenJPEG oder LLkdu nutzen bis die Turbulenzen um Emerald geklärt sind.

Scaling issues – again

Second Life is growing again, which is a good thing. The concurrency level of logged in users is reaching new heights, so no one really knows why at the moment, and if it is going on like this we are going to have around 70K users logged in in two or three weeks. Nice.

What’s bad about is, is that the underlying architecture of the grid is still the same and while it’s been able to handle the normal loads now, it yesterday started to stutter badly, again. This hasn’t happened in such drastic manner for quite some time, now. I guess it’s really time that the new architecture, which is designed to scale more nicely, should be implemented and rolled out as soon as possible.

realXtend: Second Life’s Apache?

Gentle reader,

today I want to talk a little about the realXtend project which came upon my radar recently and impressed me great lengths. Their goal is, put in simple terms, to develop the InterGrid about which Gwyneth Llewellyn spoke recently in one of her own blog posts. Well, she even mentions the project in her post.

The InterGrid, put in simple terms again, is the ability to make your own region/regions/grid and take your avatar on grid A, B or C and also take the inventory of it with you. This means your avatar becomes quite more flexible, it can travel around the different grids if done correctly, but also there’s quite much work to do until that goal is going to be achieved. This project is using OpenSim as their platform for serving regions, they’ve already enhanced it with quite much advanced and sophisticated features and also forked the Second Life viewer into an own thing, although this can still connect to the Second Life grid in a compatibility mode.

The realXtend project is backed up by two Finnish companies and around 20 people working on it, programmers, content creators and graphic designers, so a good size but still small compared to the staff of Linden Lab.

Contrary to the culture of Linden Lab, though, they’ve got a roadmap, and since they’re contributing to OpenSim, parts of it overlap with the roadmap of that project, too. Having a roadmap never hurts, on the contrary, it is always nice to have and a good thing for all participating people.

In a recent interview one of the driving forces behind realXtend, the CEO of one of the companies backing it up named Tony Manninen, gave us a very interesting peace of his mind and his over all vision for the project:

Me: And how will the work you have done on the avatar server alleviate this problem unless SL, WoW and other cooperate on interoperability?

Tony: Think of it more like the 3d web. realXtend/OpenSim is like the Apache of virtual worlds, rexViewer is the Mozilla or Firefox of whatever. When "surfing" the web, you are not constantly required to prove and change your identity when loading different pages.

And this line is quite interesting for all of us. Apache is today the work horse of most web servers on the planet, its market share is around 51% in April 2008. But what many people don’t know is how Apache started and how it became the king of the hill. In former times, when Apache was non existant, there’s been another 800 pound gorilla of webserving software called NCSA httpd. This was back then the leading webserver under an opensource license. Apache just started as a patchset (Apache was just the nickname for "a patch" first only or more precise "a patchy server") way back then for NCSA httpd, adding features many people wanted but the maintainers of NCSA httpd were unable or unwilling to include. So over the time the patch set became more and more important, popular and turned into an own piece of software, winning big grounds against its father until NCSA httpd became obsolete and went into insignificance.

So, what does that mean when talking about Second Life? Simply: realXtend could be the nail into the coffin of Second Life.

So, what’s in realXtend viewer and OpenSim already, that would be nice to have in Second Life, but isn’t there (yet)? Among already implemented features those biggies:

  • the ability to host your own region somewhere on a server of your choice and to connect it to the grid (many would like that since the tiers you’ve got to pay for Linden Lab are quite expensive),
  • the use of a more advanced opensource renderer named OGRE, which also is going to support DirectX rendering on Windows platforms,
  • coming with this renderer real time lights and shadows of objects,
  • web on a prim,
  • builtin VNC viewer for desktop sharing,
  • VOIP client and 3d audio rendernig,
  • meshes instead of prims – this means you can build far more advanced structures, also build stuff in normal programs instead of the client and import them, which adds to a good graphics experience quite much, but also means a slightly longer loading time perhaps, but still many would applaud them in SL and with right,
  • quite more sophisticated avatar meshes, everything can be an avatar, e.g. also mushrooms (this example is included) or a bad snowman,
  • Python scripting,
  • teleports between realXtend and Secondlife,
  • script controlled teleports,
  • centralised avatar storage to move the avatar between different grids,
  • multiple streaming URLs per parcel,
  • and others,

but those are the real biggies. If you also take into account that it just took realXtend to implement those features around four (!) months of time you’ll really have to wonder why Linden Lab hasn’t done that themselfes already!

Among the roadmapped features you’ll find those things:

  • Direct3D rendering on windows platforms,
  • support for OGG Vorbis,
  • support for video codecs beside Quicktime,
  • Weather support,
  • inverse kinematics,
  • avatar face/head animation based on live video camera data,
  • lip sync for VOIP,
  • cloth physics,
  • vehicle support,
  • the ability to hold more than 100 avatars at the same time in one region by splitting up the region on several hosts and letting them do their work,
  • and others.

So what we’ll have here is a real ambitious project to build the InterGrid with nice goals, but they’re not only having a roadmap, seems they’ve already been able so far to deliver their planned features and are going to be in the future, too, in many parts they’re already ahead of Second Life quite much.

To put it short: what we’ve got here is a major competitor emerging for Second Life and even more so on a very rapid speed! Linden Lab is still ahead of its competition somewhat, but realXtend is gaining ground and its gaining it quickly so that Linden Lab should really be make up its mind now what they’re planning with the platform in the future, otherwise it is quite possible that they are going to face the same fate as NCSA httpd or Netscape: the technic will remain, but innovations are coming from other sources and the people behind the initial project are loosing the grip on it.


Technorati : , , , ,
Del.icio.us : , , , ,

Opensource viewers

Since the opensourcing of the client side of Second Life there have been some more or less interesting projects going on in forking the browser or developing it into something better/more.

Some projects especially are worth mentioning there:

  • ShoopedLife. This is basically a viewer that people use who are concerned about their anonimity (haha!). Well, the original client sends some kind of information about your hardware (seems to be the MAC-address of your network interface and the primary partition ID of your first hard disk drive) to the LL server to identify your computer regardless of your login, so that they can permban you if necessary. ShoopedLife circumvents this by sending just some random address instead, so that you can still login even if banned. Griefers love this client very much because it allows them to still login in such a case. Of course, you cannot login with the old account but are then able to make just a new account with trash mail address since Linden Lab will be unable to identify your computer.
  • realXtend viewer. The target audience of this project is much broader than ShoopedLife. realXtend is a fork of Second Life, so to speak, it has a Second Life compatibility mode builtin but also can connect to much more in graphic terms advanced OpenSim-grids, which is it real use for now. At the moment it’s only available under Windows, Linux and Macintosh are going to follow later. Although still in the beginning, this project already shows much promise and is for sure going to be a real competitor for Second Life.
  • RestrainedLife viewer. That’s for the BDSM-lovers under the players. It let’s the master control certain aspects of the subs viewer, e.g. attachments cannot be taken off anymore, communication can be blocked of the subs and other aspects can be controlled by the master, too. So – not everybody’s kind of viewer, but for sure subs are going to love it to be in control of their master, if they bought the right in world tools for it, that is. This viewer is for sure not for the normal audience of Second Life.


Technorati : , , , ,

Riding the wave or getting lost under it

In business, like almost everywhere else, it’s either riding the wave or getting lost when it waves above you. Making a revolution or suffering a revolution.

Lindenlab for long has been riding the wave. Now, that the hype has somewhat gone, it needs to establish Second Life as a more stable platform than it is today, because the competition like OpenSim is catching up and up more and getting stronger. It still has its advantages above other platforms, but needs to communicate those more.

In her latest long essay long running citizen Gwyneth Llewelyn asks about if bad communication practice is the root of all evil, let’s just say for short, she’s got some valid points. Communication has flown to other kind of meanings, it’s still there, but needs to be polished up.

Another main problem she’s raising is Lindenlab’s missing to produce a roadmap and their inability to work out and work on timelines. That’s quite serious stuff.

One of the main problems with SL today is that it doesn’t really scale very well. This problem has already been known about the last two years and shows up everyday more and more when a certain avatar threshold of concurrent logins has been met.

The technic behind Second Life has some bottlenecks and shortcomings. Think about it as an analogy like a Ferrari powered by a lawn mower engine. Looks good and all shiny, but cannot deliver the promised power. Yuck.

What Lindenlab has got to do is to build a new engine, that’s hard enough, but also to put it in the car while it’s running, and that’s quite a hard feature to achieve. We’ll see if it ever happens or not.


Technorati : ,

Login worries

Some days ago there’s been the news that IBM is going to build their own server farm with the Second Life server side on it.

Well, frankly said, I can understand them. That convoluted mess that Second Life today is is all but a worthwile investment if you’re a company. If you want to have a good experience with it, better stay away from the main grid and build your own farm, your own island.

If you’re thinking about investing in SL, better do it when the grid has more stabilized. At the moment this would just be a great waste of money in my opinion given the bad performance all inhabitants of Second Life have been experiencing since months now.


Technorati : , , ,