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
