torstai 25. marraskuuta 2010

Name the File Extension

The Days of Tundra are drawing closer and we're facing some interesting decisions. One of them is the file extension for Tundra scenes, now that sharing full scenes (and parts of them) is so simple. Toni Alatalo wrote the text below on the realXtend mailing list and if you have opinions, please contribute. Anyway, here's Toni:

I think we are really close to being able to release a kind of preview demo of Tundra, i.e. Naali with the server module & executable. One key is that Jukka wrote a nice doc about how to use the document/scene/application files and explanation of what they are, and I changed the public doxygen to use the version from Tundra branch so the page is up at . I think we basically just need to write a little more usage docs to at least point to where the example scenes are and make an installer.

As you can read in the doc, the local server works nicely as a preview / editor thing -- it is not only for people who want to host servers, but also for e.g. modellers, texture artists and scripters to easily see how their things look and work in ReX. The server executable is a normal Naali app, shows the scene using Ogre etc (but you can optionally run it without gfx for server usage). A bit like the local scene preview in Naali now, but much nicer and faster 'cause you don't need a server connection anywhere -- just run Naali standalone to view local files. By clicking a file in your file manager so it starts Naali showing that scene. Besides these own document files in the internal format, you can of course also import dotscene files as well, and there's support for not only Ogre meshes but Collada too etc.

There is one non-technical issue remaining, and I feel a bit stupid to bring it up 'cause is kind of nitpicking, but it is something we should get right the first time so is worth some consideration now. It is the file name extensions that I was asking about in sprint planning as well. We talked about with Antti yesterday but didn't conclude and he suggested posting here to get ideas & feedback, so here we go. Because the issue is non-technical and I'd like to hear user opinions, decided on last minute to post this to users list instead of the -dev list.

Currently, like that doc says, we use 'txml' and 'tbin' for so-called Tundra files. Previously they were just .xml and .bin but the guys added the t* to make them unique for registering to operating system so that opening them directly to the right application works. There is a couple of problems with these names:

1. That entity-component serialization system is not really Tundra specific, is not in the server module and not tied to any protocol. It is implemented in Naali core and was originally and will used with Taiga (to store Naali EC data on opensim, started in last March or so). I've been testing the idea of calling the format the 'realxtend format' instead, and it seems to make sense. Matti K. at least agreed in the meeting. The counterlogic here goes that Tundra is the name for the design, the legacy-free usage of pure EC data for making everything without things hardcoded in e.g. LLUDP / SL assumptions. And that Tundra is a strong nice sounding name! With this logic if there are some day other implementations that support the Tundra way, they also implement the Tundra protocol and the support for Tundra files etc. .. e.g. a modtundra to opensim? This might be confusing though 'cause otherwise Tundra is the name for the server module implementation in Naali. One funny point with the current 'txml' and 'tbin' names is that 'cause Taiga also start withs T, we could say they are both Tundra and Taiga files :)

2. Erno argued that there are also many other XML (and of course binary) files used with Tundra (i.e. Naali), and I think that's a good point. For example the module loading configuration files are xml, in modules/core/*.xml -- those could be called 'tundra xml files' as well. It would be good to say what is in the file in the name, and in one way it is the scene. Jukka's doc also says "a scene file". So Erno was thinking .rts for RealXtend Tundra Scene could be it, which is logical enough but I don't think that sounds too great :o (even though one idea with the generic EC model is to allow making Real-Time Strategy games :)

I was now thinking of these extensions again, but now with better logic:

.rex - RealXtend Entity XML (earlier just thought it's RealExtendXml :p)
.rxb - .rex binary (rxb just sounds like 'rex in a tight binary form', doesn't it?-)

The files are exactly the entities, the whole idea of the formats is to store the entities, either a full scene or just some selected entities. There is nothing else in the files, not for example assets like Collada .dae files can have (dae is 'digital assets exchange'), nor some generic Tundra config stuff .. only the entity-components with their attribute values.

Opinions? Please anyone tell yours, this is for end users, you don't need to be a dev to be a stakeholder .. these are the files you are gonna be using to do work with your stuff!

For folks familiar with OpenSim files, .txml/.rex files are like the files that save-xml2 writes -- have the full scene, with asset references, without assets themselves. To make a bundle with assets like OARs are, you can simply make a zip with e.g. a folder with the assets. I guess we must come up with a name for these zips later too, like OAR is (they are tar gzips). If OpenSim gets the generic EC stuff to core some day, then OAR and tzip/rexzip files may become the same.

torstai 18. marraskuuta 2010

The Tundra Project

When the realXtend project started in the fall of 2007, two different technologies were chosen as the starting point for development; the OpenSimulator server (based on reverse-engineered Second Life servers) and the open source Second Life viewer. The platforms were chosen as the best available candidates considering the rapid prototyping necessitated by the project’s six-month schedule. Even in hindsight the choices were good, despite the negative issues encountered further along the development.

The prototype produced during the first stage of the project proved successful technology wise and it gained a fair amount of positive publicity. The licensing and technology of the Second Life viewer had been somewhat problematic from the start and the situation was getting worse with increasingly ambitious technological goals for the project. It was also obvious that the licensing (GPL, or rather the interpretation of GPL in the open source virtual worlds community) would make it very difficult to form a strong community of developers around the project.

Early 2009 saw the emergence of the Naali project. Naali (Finnish for arctic fox) is an entirely new viewer built from scratch (of course utilizing existing suitably licensed material where possible) with the intention of eventually replacing the Second Life –derivative first generation realXtend viewer. During 2010 this goal was achieved, currently Naali has almost all relevant functionality of the earlier viewer and surpasses it in a number of critical categories.

To make server development easier, the realXtend server side enhancements were modified into a module called “ModreX” and a suitable module interface was created to OpenSim. The ModreX module provided more flexibility on the server side and the OpenSim project itself made progress towards its goal of being a flexible platform for virtual worlds hosting. Even so, it still remains a relatively heavy service in terms of hardware resources, requiring several ports open in firewalls, database installations etc. Despite an increased level of flexibility, adding support for the core Naali features (namely the entity-component based content authoring) still wasn’t simple by any means.

The Tundra Server

The development of the Naali viewer progressed at a good pace and in the summer of 2010 initial research indicated that it would be fairly straightforward to add a server module to the viewer. The Naali server module was named “Tundra” and the development work was started in early autumn of 2010. With this approach it was possible to create a perfect counterpart for Naali, since much of the Naali code would be used as is. Also much of the programming work done in the future would be usable on both the viewer and the server side. The approach is quite common in for example many contemporary games and offers some intriguing advantages.

One of the immediate benefits is the “single user mode” or the ability to view content directly with the Naali viewer, without a connection to a server. At the same time it becomes possible to share content as well, which in practice means the availability of “ad hoc servers”, much like in games that allow users to host multiplayer events. In comparison, OpenSim (or Taiga) is ideologically more like a massively multiplayer online game that runs on a persistent dedicated server. The former can be made lighter and simpler to deploy, which makes it suitable for a number of applications. A notable difference is the new protocol implemented in Tundra; after researching several possibilities the developers decided that the fastest way to move forwards with the project was to use a BSD-licensed protocol known as “Kristalli”.

Naturally it is also much simpler to experiment with new features when the codebase is shared by both the server and the viewer and the current developers are of course already familiar with the Naali code. The API is also shared by the server and the viewer, making it possible to utilize the same Javascript or Python code in both. All of these features are intended to make creation and deployment of diverse applications simpler and more cost-effective.

The Second Life architecture and thus to an extent OpenSim, have a fairly specific scene model based on separate primitive objects, avatars, terrain etc. realXtend has a flexible entity-component based architecture, whose purest implementation exists in the Naali / Tundra combination, which is directed more towards being a generic 3D application platform instead of a specific kind of a virtual world. For creating large multiuser virtual environments OpenSim offers many advantages, like for example safe sandboxed LSL scripting for user-to-user content.

Interoperability between different worlds is an important question. The obvious first step is the ability to create content in ways that make it possible to utilize it in different environments. Tundra supports a number of different 3D model formats, making it backwards compatible with Taiga (OGRE meshes), Tundra also has support for the Immersive Education Initiative’s chosen open library format (Collada). The next step for interoperability is a universal authentication / identity. Tundra is designed so that adding different authentication schemes (including none or just a simple ad hoc password authentication) should be simple. The most difficult challenge is functional interoperability, currently there is no simple answer. Tundra has support for popular Javascript and Python scripting engines, but true interoperability in scripting will require a lot of work and co-operation from all virtual worlds providers.

Perhaps most important of all, Tundra is a demonstrator for the new Naali-style architecture and content creation features. Building the features on top of OpenSim based Taiga would have been more work, but not impossible and as Tundra matures, it will act as a reference implementation anyone interested in its content creation abilities can learn from. It’s also important to note that despite all the differences, Tundra and Taiga still have similarities and many of the features are already supported on both platforms. Thus adding full support for the new features and full compatibility for both platforms is well within the realm of possibility, OpenSim internals permitting.

maanantai 15. marraskuuta 2010

Blender, Python & realXtend

Pyppet has published a blogpost on his realXtend and Blender related work here. A pretty interesting read for the more technically oriented readers.

maanantai 6. syyskuuta 2010

Building with Naali

I have been working on build mode for Naali for some time now. We have had build functionality for a long time with the 'Object Edit' UI. At some point it became a bit too crowded and other tools like component editor started popping out. We tought that we need some central place where you have your build tools. Anyways it's nice to have your normal UI on where you communicate with others and interact with the world, and another where you build your world with nice tools. I decided to make a new scene so I could have all the screen space for myself. When you enter build mode all your normal Naali UI will hide and the build tools come out.

I think the build mode has now ported most features from python Object Edit tool and it combines your inventory and other build tools into one work space. There are still bugs but you can already do some interesting things with it. We are trying to move to using entity components to add features into world objects. I've made a video that shows you some components as light and web content on a object and also other stuff like how to use URLs from web or from your webdav inventory as your 3D models, textures and sounds.

Here is the youtube link, I recommend wathing it in HD and full screen so you can actually see what I'm doing with the UI.

When my mouse is out I'm copying URLs from my text editor. Most urls are from my public dropbox, that I found to be a very interesting build tool where you keep your assets. When you update your mesh there, everyone will get the latest (if they clear their Naali asset cache first for that mesh, we are looking into how to automaticly do this via timestamp or something similar). You can too build with my meshes/textures as they are public with dropbox:


The things you see in the video will be available in the Naali 0.3.1 release that we are going to make next week. Please let me know what you think and what central things you might be missing.

P.S. Seems like youtube didn't like my music choices and has desided to block the video for Germany. Here is the direct link to download the video for our German fans and others too:

Best Regards,
Jonne Nauha
realXtend developer

torstai 2. syyskuuta 2010

3D in the 3D Internet

If you're browsing the 3D Internet in 3D, is it a 6D or a 9D experience? What about if you're browsing the 3D Internet in 3D in a CAVE where you're surrounded from at least 3 directions with walls full of graphics, 9D or 27D?

Ok, back to business. Philosophy is best left to philosophers, I was just momentarily carried away when I saw the latest Naali development version running with anaglyphic stereoscopic rendering. If you have red/green glasses, you can check out the result from the attached screenshots.

On another note we've also been working on CAVE rendering. Tests with two screens have been pretty promising, now we're waiting for an adapter to be shipped from Germany so that we can test with three.

From the previous posts you've already seen how Naali can be run on a mobile device and I have to admit that it has been fascinating to see the development in the other end of the computer power spectrum as well. Now it's possible to pick up Naali and go if you have a high-end mobile phone and if you get your hands on a CAVE system (they're not very easy to come by), you will have a very powerful immersive experience.

The 3D rendering option will be released in the next binary (0.3.1) at the end of this month, the code is of course already available.

torstai 26. elokuuta 2010

Nokia & Intel establish first joint research lab in Oulu

As many of you probably know, most of realXtend development has been done in three companies based in Oulu, Finland. LudoCraft and Evocativi (then ADMINO technologies) have been involved since the beginning in 2007, Playsign joined the project officially in 2009.

We were all happy to hear the news and honored about the opportunity to present realXtend at the event when Nokia and Intel decided to found the joint research lab at the Center for Internet Excellence. Many of the realXtend developers have graduated from or are still studying at the University of Oulu where the CIE resides, which naturally leads to us having good contacts there. Not to mention a degree of pride for having two industry giants choose Oulu as a location for the joint research center.

Here's a couple of links to more information:
Official CIE website
Nokia blog
Intel blog
Maxping articles by a former realXtend program manager Jani Pirkola

torstai 13. toukokuuta 2010

Naali 3d canvases & mediaurl handling

This text was originally sent to the realxtend-dev mailing list.

Thanks to Jonne's efforts recently, showing qt widgets as textures in the 3d scene in Naali is back working again. And the old textureprop/genericmessage mediaurl handling that I wrote using it in December is now enabled in develop and uses that new implementation for display.

I had a little fun with a custom use of this yesterday -- this video shows a html+js animated webpage as the texture of avatar's shirt: . The webpage used there is which is good for fps testing, has an fps meter for the own drawing. In my setup had refreshrate 20fps for the 3d view, and naali on linux kept running >50fps, while the qwebview was running bubblemark with defaults at 40-50fps (external window). All looked and felt smooth, and was fun to resize the 2d view to scale the bubbles up in the texture :)

The EC_3DCanvas is basically identical to the EC_UICanvas implementations that was in the old qtmodule last year, but instead of the uicanvases we had then for both 2d & 3d display, this takes the qwidget directly as a param. But input, which worked fully with the old system back in October or so, is not yet implemented at all. Dealing with the focus etc. is the tricky part that Jukka has been investigating.

The actual mediaurl handling nor the 3dcanvas itself don't yet have any UI for opening the same widget for 2d display, where input works. My test uses little custom code that put to I leave it there, so in the upcoming 0.2.2 release if someone wants to play similarily can go to this line in pymodules/usr/ if 0: #webview as 3dcanvas . Change 0 to 1, and press alt-. inworld to see it. You can change the urlstring in the code snippet there, and modify the submesh/material indexes too (default is [0], so assigns to the first mat index of the user's avatar). This test code is local only, not synched in any way, so only you see it. The 2d view of the widget this code opens is an external window.

A use case for mediaurls is where the webview is showing something like etherpad or google docs, which updates live in the inworld view, but which can also be opened for editing. We plan to use this in an inworld rex testing workshop with the French Ener team next week. The workaround with current code is to put a server side script to the same object that is having the mediaurl to send a LoadURL command when the object is clicked. That will give two separate webviews, where scrolling the 2d one doesn't affect how the 3d one is scrolled or anything. Just now realized that that is the desired behaviour probably anyway, so your inworld view keeps showing the same that the others are seeing too. But still some UI for opening any 3dcanvas for 2d view is probably good, in client side without needing custom server side logic .. with a
mouseclick or something.

How to scale, offset etc. arbitrarily sized web pages by default etc. is AFAIK a bit of an open question still. Do defaults work ok or should that be configurable? I haven't looked yet how the new shared media thing in slviewer works.

Besides the old rex mediaurl genericmessage handling, I also started writing now a EC_WebView as a test, using the new Attribute system in Naali which gives automatic net sync of component data. This would be much simpler and robust than the texture mediaurl handling, and also allow adding new features easily .. like synching the scroll offset when
desired or something.


P.S. oh and the use case for showing something animated in the avatar's shirt is another request from Francois -- have videoconferencing work so that participants video shows in the av t-shirt, while the av face etc. remains for av animations etc. I had thought of having avatars with box heads where the video shows where the face is, but agreed that his idea is better :) .. should be easy now with the comms module video call videos, 'cause they are already shown using a qwidget. And Francois was thinking it could be also just showing a webcam image of the avatar's user, doesn't necessarily have to be naali which sends the video. And of course doesn't have to be the full shirt texture, I guess putting a video/webview plane as an attachment to the chest can work simply and well?

P.S.2 about video in these webviews: qwebview doesn't support flash out of the box, so youtube etc. doesn't work now. That's why I used the bubblemark html+js thing for fps testing. Hopefully qwebviews get html5 video tag support soon (and youtube etc add support for something else
than h264 so that open source software can show the videos?). Using a qvideowidget should work, but I don't know what formats+codecs are supported there - Matti K. etc. I guess know based on the video calls work.

keskiviikko 21. huhtikuuta 2010

Naali on the Nokia N900

If your not a big reader skip to the bottom and at least check out the video!


I bought a Nokia N900 phone recently. It's a great device and has a lot of potential with the linux based Maemo5 OS and the processing power. First I made some simple small application in Qt to test how it's done and learned a lot. The thing was that these application didn't do or show anything that could be useful for anyone.

Hmm... why not build Naali for that thing? Is it too heavy to run, what about the 3D rendering? What about building Ogre and all the other dependencies? Only way to find out is to give it a try. I had a 4 day easter holiday (extended weekend) coming up so I started the home project then. I made slow but steady progress during these days. Building ARM versions of Ogre and all the deps were the biggest challenge for sure.

Naali itself didn't need that much work, just disabling some modules and I got myself the first build. As an end result I had Naali that started from the terminal and opened a QMainWindow that had ogre rendering to it. The UI was not showing, the window was just black. Oh... I also had one pissed girlfriend for not spending the holiday with her. She watched/listened me swear and curse on the computer for days, thanks Susanna for putting up with me ;)

On the next workday I showed this "thing" to my co-workers. Didn't get that good of a welcome as... well it didn't do anyting. So next few days I worked on actually showing something and doing a login. I made a simple timer into rexlogic to blast a hardcoded login away when Naali was done loading. And what do you know, it went in and showed me a bringht yellow Audi world. As I later discovered it was the EnvironmentModule doing this, it also crashed the viewer every time terrain was fully loaded. So I disabled the module, after that everything started to load and most importantly look good with the GLES rendering. Of course the sky was black and terrain had no texture due to disabling the module, but our target world is indoors so that didn't matter at the moment.

Next I showed this thing at work and then I got some peoples interest peaking. Then it became my job to make this thing "working" and in demo shape in 1-2 weeks. I took the challenge, did my best and here is the result.

The video demos everything I've managed to do so far specifically for the Maemo platform. This includes removing the normal Naali UI and remaking a simple UI for the interactions that we were interested in, without obstructing the world view too much. Some small adjustments in the window creation. I also tweaked the input system to work with a touch screen and made some special camera controls. Probably I missed something, small changes were required here and there.

Check out the video at

Best Regards,
Jonne Nauha
realXtend developer

perjantai 19. helmikuuta 2010

Using Facebook chat with Naali

Since Facebook opened its chat to Jabber/XMPP clients, it has been available to be used with Naali. Now you already can have your Facebook friends list in Naali and chat with people with it. Voice chat, however, doesn't work, because the Facebook chat doesn't support it. You can view your jabber id and server settings from the Facebook guide.

torstai 11. helmikuuta 2010

New UI in development

The new Naali platform is still some way behind the original realXtend viewer when it comes to feature completeness. It seems that our original predictions were correct, however, and the new technology enables us to create new features and fix issues at a high rate. One of the aspects we will be looking into a lot more in the near future is the user interface.

Until now UI design has been driven by the need to have some kind of a way to access the functionalities mostly for testing purposes. After the release of the 0.1 version (Don't forget to pick yours here) we will be concentrating a bit more on the UI side. Here's a brief explanation on the new approach by Jonne Nauha (typos are all mine):

Ether concept

We have had some actual UI design meetings now and decided on some high level consepts. One of them is "ether space" versus "inworld space". Th e aim is to have "ether" as the view where you land in when you launch Naali. It will be the place to make logins, create new avatars, create new worlds and possibly access tools/settings for the viewer. We would like to get rid of the "write your information to these text fields" approach. Of course this is somewhat necessary when creating avatars /worlds, but in basic use the workflow should be "I'll pick this avatar, I'll pick this world, ok lets go" -type of thing.

We tried to think of a simple and at the same time nice looking and inviting thing, so we started prototyping a "flip book" type of thing that resembles iTunes cover flow, but for virtual worlds. Me and Mikko Alaluusua have worked on this for a few days now and have got something together already. We did this out of Naali codebase with QtCreator and used pure Qt, namely the Qt animation framework is used heavily. The cards get loaded into a scene that is shown in a full screen graphics view, so it will be easy to port into Naali.

The fps in my capture software was too low to show the animations fluently and somehow it altered the colors too, but you should be able to get the idea. The navigation is WASD or arrow keys, and we'll add mouse selection functionality to the "cards" too. The background image and other graphics are only for prototyping, not what will eventually be included in Naali. For now the avatars have the basic image of the naali (arctic fox) and worlds all share the globe image. The idea with the images is that your avatar's screenshot will be inserted there and it is updated when you change your appearance or logout (not really decided yet) and for the world images a screenshot is taken from the position you last left the world in question.

Inworld widget interaction

The inworld widgets will probably stay with the slim frame or maybe some styling will be done there with proper graphics. The main thing inworld would be to get rid of the age old toolbar at the top of the screen. We are now close to 10 widgets and they will only increase in numbers when we go forward. We were thinking of giving each corner inworld a certain type like widgets on the top left, notifications / status things on the top right, messaging on the lower left etc. Of course the positions or the final look are not firmly decided yet. But at least I would like to remake the "widget toolbar" into something icon based and add some snappy animations like some kind of a layered menu that has sub groups for widgets like interacting, world building etc.

Also some kind of workspaces would be nice to make. So you could make different UI views and swap between them fast to get to your tools. A little bit like operating systems have multiple desktop views that have their own set of applications and you can move apps between them.

UI for interacting with objects and people

We also need something similar to pie menu we all know and love/hate :) There hasn't been any decisions about this yet, but some kind of a hovering "info card" for things you want to interact is the goal. This infocard could follow the avatar / object that you have interest in or it could be pinned to a position. The idea for these cards would be that there would be a viewport (camera) to the item, for example the avatars face that you clicked or movable view of a object you are interacting with. Also this card would have quick selections for sending messages to a user etc. This will also be the most challenging thing if we do it purely on Qt that needs an ogre viewport rendered to it. Right now all info that is showed of people is a static 2D overlay that has the avatars name. And if this is the best we can do with ogre then we probably go with Qt on these infocards.


The aim is to get most of this done by the march release. It may be that "ether space" will have 70% of the defined features, inworld "info cards" 50% etc. as its hard to know what obstacles there will be ahead. Especially when our Ogre+Qt is a special thing without paint events that there always can be something unsuspected outcomes of this, good example is that we had fully working video calls in Naali IM before we moved them inside the scene and now gstreamer doesent render the video to the window handle.

maanantai 18. tammikuuta 2010

Naali 0.1(first public rc) released!

This is it. There are still a number of bugs to fix (some of the code heroes sitting right next to me are currently hard at work fixing and tweaking) and an incredible number of new features to do, but as the version number 0.1 suggests more than a final product this really is a glimpse of things to come. Nevertheless and although I might be considered partial, I still think it's already quite interesting and suggest you try it out for yourselves. Let's take a quick look.
Lisää kuva

Swimming with the fishes is as pretty as ever. There's of course a lot of room for optimization, but the graphical capabilities have traditionally been one of the focus points in our development and that won't change with the new Naali viewer. You can connect to existing realXtend and OpenSim worlds (sorry, walking between regions is still in the works) or host your own with the realXtend server (new version to be released soon).

Here's a shot of the user interface. We're currently working on enhancements to the visuals and a new layout for the UI, this is an example of some of the functionality. Note that I'm logged in with my Jabber account, which makes it possible for me to communicate with the outside world as well. Currently it's also possible to make video calls (and only video calls, yes, we're working on it) and we have quite a few ideas about future development for the communications module.

Ok pay attention, everyone, because now comes the really important part! We started the work on the new viewer and server software because we had a lot of ideas on how to improve realXtend, but the software architecture we had at the time didn't offer the kind of room for expansion we were looking for. Naali does. And not only room for us to work with, but for everyone interested in it as well. realXtend is an open source project where everyone can participate. The code is available under the liberal Apache 2 license, grab yours today right after you test the binary we prepared for you.

We would love to have your input on what you think about the new viewer as well as the bug reports that will inevitably be generated now that more and more people start testing the software. From now on we intend to make new binary releases more often, which means you will get to see the new features relatively quickly even if you don't want to build the code yourself. The Naali viewer is designed to be cross-platform and we have run tests on Linux, Mac support is on the way as well. I hope there are some enthusiastic Mac and Linux users who would like to join the community and together make sure Naali works equally well on all the platforms.

Get the software here:

Here you can find discussion on realXtend software:

If you run into bugs, please let us know here (please check for known issues first):

We will be explaining the new features in more detail on this blog soon, you might also want to browse the existing documentation here: