On Aug 16, 2012, at 2:23 AM, Peter C. wrote: > I have to ask this, as I am in the finalizing stages of choosing an engine > for my project. Are you guys implying that it's likely that Tundra will shift > to a WebGL/Browser based system?
No and yes. We try to be clear about the path in the roadmap doc that was posted earlier, but I explain here too. (the doc is at http://tundra.ludocraft.com/files/RexRoadmap-15052012.pdf -- we should perhaps 'webify' that with some nice system (like getsatisfaction.com?) to dev targets etc that can be tracked etc). 1. The current C++ Tundra SDK with Qt, Ogre etc. is not going to disappear (anytime soon, if ever) * is used and maintained and developed etc., with foundation backing and in several companies with several products and for customers etc. 2. WebNaali is an early version of an alternative client that connects to Tundra, using WebSockets and WebGL etc. in browser Javascript. * it is an addition to the Tundra offering * being worked on now by 1 person at chiru.cie.fi (using three.js now instead of glge in the original/earlier version) So the answer is no because Tundra is staying what it is, it remains as native code and is not shifting to a browser based system. But the answer is also yes, because a browser based client is developed -- which applications and services eventually switch to that is to be seen (I expect CAVEs with Kinect etc. to not switch but who knows in the long run). Possibly many web-hosted online services switch, or add it as an alternative client technique. And also with the websockets client we are using Tundra as the server, scalability improvements etc. are worked on in c++ for the server side and the idea is that the same benefits the browser client then too. I hope this clarified the situation -- please do ask more if something is bothering still. And sorry for the delay, has been a busy week here preparing a new public world for launch. To be complete, I'm afraid I have to further complicate the picture with the two additional tracks in the roadmap / on-going activities now. Many lines of work and various alternatives are not rare in the relatively fast changing worlds of software -- in (big) companies they are often hidden, and customer eventually just sees a clear unified result later. Some generation of a software is in active use, while new generations are developed, possibly in several different even competing ways etc, but in secret. In an open source organization such as realXtend it is much more exposed publicly. Also you should note that realXtend is not a company, but just an organization formed by several companies and individuals in order to collaborate. Any of these parties or anyone else in the world is free to take it in their direction etc. The resulting development comes from whatever it is that people/companies do for their reasons. We do take strict care that e.g. the Tundra core and architecture stay intact when additions come, but anyhow I suppose you get the picture. If you or someone wants commercial support and backing you can talk with the companies. So the additional tracks: 3. Besides Tundra* and WebNaali**, we at Playsign have worked basically all this year now with a Flash client (first for the Berlin case), with simple usage of XMPP without requiring Tundra. We are continuing with this technology now with other cases, and publishing the very simple basic client code (using existing 3d and xmpp libs) as open source, as a candidate thing that realXtend may or may not adopt under it's umbrella. A repo for it is coming on-line, and there's a little doc that explains what it (Lehto***) is in relation to other realXtend things at https://docs.google.com/document/pub?id=1iJil_uoj2BBJYXG5U5wrNkjWZPn4FKr8HjfgsRObpw0. The situation with Flash is a bit weird as we do not expect or at least hope to not use it forever, supposing WebGL performance and adoption improves, but we are using it now and probably the rest of this year (and next year?) as it works better (is faster, also on mobiles with AIR, and works in Microsoft Internet Explorer too). * developed mostly by Ludocraft and Adminotech, with some cool things from chiru.cie and others too, and earlier us at Playsign as well ** developed originally at Playsign and currently by that one guy at Chiru *** the name 'Lehto' (grove, that kind of a nice forest place) is to clarify the use of XMPP instead of kNet Tundra conns, whereas Naali is a Tundra client (those are both arctic :) . As the doc explains the interplay of all these is possible: if a XMPP backend makes sense for authentication, federation etc., WebNaali and Tundra can use it too. And Flash based Tundra clients, similar to WebNaali (but more straightforward as don't need websockets, can e.g. do the kNet UDP conns identically with the C++ Tundra) are possible too -- just that Lehto is not that. 4. The roadmap doc discusses and proposes a new Mobile Tundra track -- a small and fast new client implementation in C++, suitable for phones and tablets etc. Jukka has experimented this with his GfxApi, running performance test etc. Also here the idea is to stick with current Tundra for server and creating. An interesting drift here is that the same code can be compiled from C++ to Javascript (with emscripten) to browsers for WebGL use. So we could eventually get both a native c++ client and and a browser based client automatically from the same codebase, as Jukka has demonstrated with his rendering tests. There is however no real project for this now, is in talks (we'll meet with association board on Monday and with foundation on Wednesday in fact). About mobile devices such as phones and tablets, Ogre is known and tested to work both on iOS and Android and there's some progress on building all of Tundra on those too, so mobile use is not fully dependent on that new 'mobile tundra' track. Hopefully later this year we get to run Tundra on such tablets. But the new mobile Tundra could later give us a leaner and meaner small client, and indeed something that works for WebGL too (compiling Ogre to Javascript for WebGL use is reportedly not feasible..). Unity uses that compiling approach too, at least with Flash -- they compile their proprietary c++ engine to actionscript to run the Flash exports (that's actually why we found Unity poor for authoring Flash 3d apps, because it always needs to download and run the relatively big feeling engine even for simple small apps). ~Toni -- http://groups.google.com/group/realxtend http://www.realxtend.org
