realXtend organization news

Here’s an update of some organizational and development planning work that has been going on a bit behind the scenes for realXtend. Summary: there’s a new board for the association, and we are working on a more detailed plan for the so-called Mobile Tundra track featured in the roadmap document earlier.

First a recap of realXtend’s organizational structure: The Foundation is to provide a stable home for realXtend, it owns the name etc. but does not do much. The Association, open for anyone interested in realXtend to join, is where we coordinate the actual development work. Much of that happens on the good old mailing lists and irc channels, but we have live meets here in Oulu as well.

Foundation has some basic funding, and in the association we prepare proposals for using that money. So far it has been used to hire me and Jukka Jylänki to work part-time on taking care of realXtend and especially the Tundra SDK: my time has gone much in planning and developer support when different groups for example at the university have implemented new features to Tundra, whereas Jukka has been reviewing code in pull requests and making releases. On a different front, Fred in France has been working on the realXtend meeting platform (RMP) scene and making tutorials.

This changes a little now: both Jukka and I continue in a similar way, but my part-time realXtend work will be paid by the technical faculty at the University of Oulu from now on. I’ll also be doing research on realXtend and working with the city module at the NIMO project in that work. Project and development work I will do via Playsign, same as before, and there’s a team of other developers there taking care of most of the programming. This arrangement frees some of the foundation money for more basic realXtend work — that was one of my main motivations for the change too, to get more power to push us forward.

Squash the bugs!

One concrete area I proposed for using the money was taking care of the bugtracker, sorting out the issues and fixing relevant ones etc. It does not happen automatically in our mostly project lead work, where development efforts typically focus on some specific service or product, and prioritize bugs to fix based on the needs there. Otherwise important issues may then remain open for a long time. Also in larger and widely known open source projects, such as Blender, keeping the issue count down is a constant struggle.

Adminotech, the other main developer of Tundra SDK besides Ludocraft where Jukka works, made a good proposal for cost-efficient bugfixing work. We presented that idea to the foundation which basically approved it — it is now back to the association to refine more. Antti Ilomäki posted one preliminary list of first issues to tackle in an email, we
should make it somehow visible now on the web too (perhaps assign those issues to Adminotech or so in the tracker? Or make it a milestone?). I have a good feeling about this, Tundra getting more peaceful hand-on-code attention to verify that the base is solid.

New Tundra to mobile devices and WebGL?

The other area in focus now is the so-called Mobile Tundra track featured in the Roadmap 2012-2013 overall plan we posted earlier. The idea is to write a new lightweight cross-platform Tundra-compatible client suitable for mobile devices, notably iOS and Android phones and tablets. Jukka has experimented this direction with his GfxApi rendering tests (and Lasse Öörni and Jarkko Vatjus-Anttila have done similar with their Urho3d and NeoCortex engines respectively). A basic issue with current Tundra is the relatively poor rendering performance of Ogre on modern graphics systems (no clever batching). Also Qt has not been officially supported on iOS and Android, although that has now been announced to change with Digia’s recent Qt5 news.

Regarding WebGL, the Mobile Tundra track has a special drift: the idea is to use the Emscripten C++ to Javascript compiler to run the same client code in webbrowser Javascript as well. Jukka’s GfxApi cross-platform rendering tests already run both on desktop and mobile operating systems natively, and in web browsers, from the same source code. Earlier, in the WebNaali project, we’ve used WebGL with a completely separate codebase, just using a WebGL engine and own WebSockets code to connect to Tundra. This works fine, but requires implementing all the client side functionality separately for the web client. With the Emscripten compiler it would be just a different kind of build from the same lightweight Tundra client sourcecode.

If we decide to pursue this approach for a new client, the idea is to still keep the current Tundra for server and desktop (at least authoring) use. There is no intention to write new Scene Structure and Entity-Component editors with something else — Qt and the widget’s it provides for the authoring tools are fine. There are many details to be worked out, we’ll consider more when get Jukka’s first proposal for an actual implementation plan.

Other things: Community, Flash client, ..

There are also other things on the tables, such as work on documentation, ideas about community building, and the situation with the alternative Flash&XMPP solution we developed in the Berlin case and are now using with the Haukipudas church as well.

About docs and community, the idea is to have a new assoc. board meeting — now also with Francois Garnier, who was elected as a new member to the board in the annual meeting last spring (which was successively held on-line with Tundra’s Mumble VOIP in the RMP scene btw!). Cyberlightning offered to review the website design, and they have prepared some kind of marketing material for realXtend within the 3d Internet Association, which should be coming on-line soon.

About developer documentation — the part that realXtend is missing most for more adoption — there are some great news: Adminotech has made tutorials, starting from very basics to more advanced things, and that set of documentation should hit the web soon too!

The Flash&XMPP tech, called Lehto (Grove in Finnish, to say it is not Tundra :) is better featured in a separate post later — do feel free to ask about it if you can’t wait. The v. 0.1 code is already online and the basic info is in the README there (nicely visible on the github page): . There are no usage docs at the moment, nor a minimal demo, but the Berlin Gallery Weekend world is still up and can be considered as the demo.

Many small advances are made on various fronts, for example COLLADA asset support with the Asset Import library is being integrated in a nice way to Tundra by the Chiru project at CIE, and the ZIP asset bundle support from Adminotech — we’ll post more when those and other useful things are coming to new Tundra releases.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s