I suggest you read through their website, as the github is fairly basic compared to their actual website. https://www.garagegames.com/products/torque-3d
On 01/09/2013 04:11 PM, Jonne Nauha wrote: > This Torque seems nice, I guess. The repo is very weirdly structured > for me, very hard to find the actual code. Seems they don't use a lot > of dependencies, which is good i guess. Seems to implement their own > window managers etc. for each platform, seems crazy to me but gets you > the most control :) > > Yeah it looks nice and all, but why exactly should we start porting > features from it to Tundra? It seems to have a very different use, as > in having a flexible gui editor to create projects in "click here and > here to make a game" kind of way. Is this networked at all or a "make > single player games" framework? I dont even know exactly what it is, > just by reading the readme from github it still leaves me puzzled. Can > you be more specific what would you like to see in Tundra from this? > Can you point to code/sceenshots to get some kind of idea? I doubt > there is any "porting" to be done, its a completely different beast > without all of our dependencies/libraries/frameworks. Features/ideas > can be copied (if they apply to the Tundra "idelogy") but they will > probably need to be rewritten from scratch. > > I think we can however agree rex project should focus on documentation > and examples (both c++ and javascript). Content creation tools can > also be on the table, but as we have talked numerous times (in the > issue tracker) Peter it might not be in the Tundra SDK scope to have > fancy editors and ship certain kinds of 3D assets with it. Maybe we > need to adjust that "purity goal", I don't know. I would like to see > the assets at least in a different repo if this happens and move > /bin/scenes and parts of /bin/media there too. > > I think many of the end user problems with Tundra come from that we > are a very programmer oriented thing. You can't do much with Tundra if > you don't know how to code or are willing to look at some headers. > This can partly be solved with documentation, but at the end of the > day if you want to make things move and pop (like a game), you need to > write some code either with javascript and/or c++ code. > > Tundra is a more of a developer SDK with some examples to get you > started, not a full "click a button on a editor to make a game" kind > of thing, I guess that is a quite nice dream to have. We could make > this kind of editor, maybe utilizing ogitor or just build our own, but > we would need to move our focus out from Tundra "core". I suspect that > this Torque was not made in a couple of months but there is some > serious money and effort behind it before made open source. > > Btw. We have it on our todo list to make most of these things to > Meshmoon. Nice(r) editors, easy "primitive" building, scripting > templates and drag and drop content libraries. We need to make usage > and building easier for our end users, I just think it might be more > in Meshmoons scope that Tundra cores, hard to say. I know for a fact > that if I implement these in Meshmoon I can make it just the way we > like. If I'm doing it it Tundra core I need to ask for acceptance, > deal with merge politics, go with cores UI style and in many cases > dump down or limit the implementation so that it is generic enough and > usable everywhere. > > *TL;DR +1 for documentation and modeling/scripting examples :)* > > Best regards, > Jonne Nauha > Adminotech developer > > > On Wed, Jan 9, 2013 at 9:24 PM, Peter C. <[email protected] > <mailto:[email protected]>> wrote: > > 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] <mailto:[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 > <http://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 > > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
