They open sourced the whole of Torque3D: https://github.com/GarageGames/Torque3D
It only runs on Windows for now, but they are pushing for Mac and Linux support. They are also planning on open sourcing Torque2D. I think that for inter-op it would be best to start by porting functionality Torque has that Tundra does not to Tundra, and then figuring out ways to convert content/scripts from Torque to Tundra. I was looking at Torque, and the source code it self is really heavily interconnected; it would take a complete overhaul to move it to a modern entity-component system. I personally would rather just implement the missing functionality in Tundra and make it easy to port from Torque to Tundra. On 01/09/2013 01:42 PM, Toni Alatalo wrote: > On Wed, 2013-01-09 at 13:30 -0500, Peter C. wrote: >> In regards to the game dev aspect: I'm sorry if that came off the wrong >> way, it was just the google doc read a little more like "this is an >> academic project, the focus is on professional use and not games, end of >> story". Sorry if I misinterpreted that. Also, in regards to Ogitor, I > Right, well it's me who has to be sorry for writing it too unclearly > there I'm afraid. > > Actually the strategy we hope to drive now in the research cooperation > with the university here etc. is that out of the academic work we would > get concrete improvements to the tech which would really help e.g. game > creation. > >> was thinking more build some sort of plug-in that would allow for using >> Ogitor functionality in Tundra as an in-scene editor. Also, for torque, > Right, that's what I was also wondering early on -- especially because > also Ogitor uses Qt like Tundra does, might be possible to somehow hook > Ogitor to be a Tundra plugin or something even (but not totally > straightfoward, because Ogitor uses the Ogre API directly, whereas to > integrate in Tundra nicely it'd need to be ported to the Tundra API > which wraps Ogre). > >> I have to do some more research in to it, however the main two things >> that come to mind are possibly implementing the ability to easily >> transition from Torque to Tundra. The main problem I see with Torque is >> it is based on the old multiple inheritance methods, and is a pain to >> work with when you start needing custom functionality. There are > Right - the entity-component model in Tundra has certainly proven to be > a nice strong point, has served great for extensibility in practice, is > easy to understand I think etc. > >> easy inter-op. Ideally it would be a collaboration between the RealXtend >> association and GarageGames to create the best of both worlds, but I >> doubt that would happen. If nothing else, my main concern would be the >> need to implement similar DCC as torque's editor in to RealXtend, along > Interesting - it might be a far call, but it is also good to brainstorm > with an open mind sometimes. > > BTW didn't they open source something recently, was it torque3d runtime > or what? > >> I think that the primary things that RealXtend could benefit from would >> be better documentation of how to develop for it beyond basic scripting > Agreed. As you noted, Meshmoon docs helped already, but certainly much > is still urgently needed. > > I think we need tech dev too but certainly creating those docs must be > somehow organized finally. > >> out to places like Ogre, and having an Ogre wiki page and link to >> realxtend in the Ogre wiki for 3rd party projects using Ogre, would > *nod* -- I think the time is certainly ripe to submit Tundra as a > candidate featured project for the Ogre site. Feel free to do it, anyone > basically, but I think I must if no one else beats me to it (should not > be hard..) > > Thanks again for the good points and welcome reminders (I wasn't > recalling Ogitor and Torque too clearly at all, have been quite occupied > with many other things recently too). > > ~Toni > >> On 01/09/2013 01:05 PM, Toni Alatalo wrote: >>> On Wed, 2013-01-09 at 10:22 -0500, Peter C wrote: >>>> Just a few suggestions / things to note. >>> Thanks - quick comments: >>>> 1. Even if the primary intent is not games, it would be wise to >>>> develop with the same performance mindset of a game engine. Long term >>>> viability as a platform requires keeping up with tech. >>> We certainly keep that up -- both Ludocraft and Playsign are games >>> companies, the requirements from us (e.g. Ludo's old creation tool doc, >>> the mobile tundra plan etc) are largely from games dev perspective). >>> >>> Sometimes it is more difficult for us to get a good understanding of the >>> *other* requirements, other apps besides games :) >>> >>> If you are referring to the remark in the google doc, it tries to say >>> that reX is essentially about *networked multiplayer games* (or other >>> multiuser apps) out of the box, is inherently networked, whereas e.g. >>> Unity3D was originally for single player games (though has many mature >>> ways to do networking nowadays with 3rd party addons and has basics >>> builtin too). >>> >>>> 2. It might be wise to try porting ogitor to run inside realXtend. If >>>> nothing else make an exporter from ogitor to tundra. It may also be >>>> wise to look at how torque has their dcc set up. >>> Yes we looked at Ogitor back in the early days when considering options, >>> I was repeatedly showing it to the guys in sprint meetings etc .. and >>> read some of their code when considering editing things in Naali/Tundra >>> etc. >>> >>> Both Tundra and Ogitor support the old simple Ogre dotscene format so >>> they might be interoperable already, i.e. you might be able to import >>> Ogitor authored scenes to Tundra. When I tried dotscene things in Ogitor >>> 0.3 some 2-3(?) years ago, though, got only some crash then, dunno about >>> the status of dotscene vs. their own format there -- certainly worth a >>> new look, it always has seemed like a good project. >>>> 3. It may be a good idea to look at porting torques functionality to >>>> tundra. I was recently doing research on torque, and they have a >>>> massive community, but their architecture is really bad. Don't count >>>> out game developers as a possible audience. If you were to outreach to >>>> game developers, and they were to get involved in improving the game >>>> engine side of things, it would benefit the academic side too. Games >>>> tend to be one of the biggest driving forces of technology. >>> Yes, I actually tested it for some reason last year a little and thought >>> there were nice things, certainly also worth more study. >>> >>> Scripting / Logic authoring has been my pet peeve for long, and still >>> kind of sold with the Scratch design for very simple things at least >>> (for kids and non-programmers), and both Google Blockly and Waterbear >>> would seem to allow it nicely for Tundra-JS. >>> >>> Do you have some things in specific in mind about Torque, does it cover >>> everything a bit like Unity, dealing with assets etc? I'm recalling the >>> game maker things with events and states and something for logic etc, >>> hopefully have time for a study soon enough (or someone else has). >>> >>> ~Toni >>>> Cheers, >>>> Peter >>>> >>>> [email protected] wrote: >>>> Hi, >>>> >>>> we had a semiofficial(*) realXtend association board meeting >>>> yesterday, mostly to discuss and organize further planning on >>>> development roadmap for the new year. >>>> >>>> My full notes are on-line, main point summarized here: We >>>> decided to plan work on two fronts, creation tools and >>>> pipelines coming as a new primary focus. The other area is the >>>> tech platform & engines topic which was already worked on a >>>> lot last already (the realXtend roadmap doc from last spring >>>> discusses the three areas there, i.e. current Tundra, browser >>>> based clients and the Mobile Tundra unified light client >>>> idea). >>>> >>>> For the creation tools and pipeline we agreed to gather >>>> wishes, requirements and development proposals and meet again >>>> on Thursday next week (17th) to put together a plan. >>>> Ludocraft made one report on this already ages ago, they’ll >>>> check if parts of it are still valid. Francois will talk with >>>> Matteo and Francois from Spinningwire and ENER labs. >>>> Adminotech has some concrete needs, I think largely coming >>>> from VW use in education. I think Evocons at least can tell >>>> what they need in their work with the building industry. >>>> >>>> You, anyone, can also use this chance to inform the planning: >>>> what would you need to be able to create applications, worlds >>>> or whatever with realXtend better, or is that even a >>>> bottleneck for you now? Even vague ideas are welcome but the >>>> more concrete a plan the better of course. >>>> >>>> Some things discussed in the meeting: more example assets for >>>> e.g. use of different materials / options of the SuperShader, >>>> creating a new shader library. Better scene/ec editor with >>>> grouping etc. A question: is tighter Blender integration, for >>>> example with live material preview with a Tundra window as >>>> demonstrated by blender2ogre, a good way to author or is >>>> something else better? >>>> >>>> The full notes with some additional points are in >>>> >>>> https://docs.google.com/document/d/1IqS7Z9WUy_7jt753oSnt3HE0ISQXhT4zstP71A_6FKY/edit >>>> (not too structured, sorry). >>>> >>>> I think we can use this mailing list / google group to gather >>>> ideas and discuss, but am also interested in more structured >>>> ways. For example getsatisfaction.com has seemed nice for >>>> working on feature requests, I think I saw Kitely using that >>>> long ago and tested creating a realXtend account there too, >>>> but I don't have any real experience on using that or any >>>> other similar service. Github issues serve well for actual >>>> todo items and feature wishes too but I don’t think it suits >>>> this kind of requirements elicitation. Am open for >>>> suggestions, either here or privately. >>>> >>>> Finally, I’d like to explain a bit the rationale for the focus >>>> on creation tools as how the common interest focused there >>>> surprised me. I have earlier thought that there is a big >>>> divide between a)professional creators and b) supporting easy >>>> end user content creation. Basic realXtend offering, e.g. the >>>> Tundra SDK and the little WebGL and Flash clients, target >>>> professional creators -- people who are comfortable with >>>> normal 3d modeling and programming etc. More Second Life or >>>> Facebook style end user creation are implemented in custom >>>> applications, for example the TOY content tools which are a >>>> now a part of the Meshmoon offering, Cyberslide where you can >>>> just create a scene from your Powerpoint slides, or >>>> Ludocraft’s sandbox. But yesterday the common understanding >>>> was that there are many things that we could do to help both >>>> professional creators and services with user created content. >>>> Ease of creation is of utmost importance in professional use >>>> as well as it of course affects both the quality and >>>> especially the cost duration of projects. Also we figured that >>>> work on creation tools is relevant in any case, no matter >>>> whether we end up using Ogre, some other native engine, or >>>> WebGL more in the future. >>>> >>>> so here’s a starting point for the year! >>>> ~Toni >>>> >>>> (*) not everyone in the board could participate yesterday, so >>>> we postponed some administrative bureaucracy for a later >>>> meeting and focused on the dev planning work >>>> > -- http://groups.google.com/group/realxtend http://www.realxtend.org
