reX assoc board meet: focus on creation tools
65 views
Skip to first unread message
to...@playsign.net
Jan 9, 2013, 2:45:32 AM1/9/13
to real...@googlegroups.com
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
Peter Steinlechner
Jan 9, 2013, 10:11:54 AM1/9/13
to real...@googlegroups.com
Hi Toni
Happy new year to everyone in the group. Its great to see how the realxtend project progresses.
Some things that come to my mind to wish is about enhancing the COLLADA import by using zipped COLLADA files like the Khronos suggestion of .zae files and a drag and drop feature to upload them like it is in open wonderland.
The way how it works right now is allready great, but I think I wasn't the only one that tripped by the upload, before finding out that a placeable has to be assigned too.
Maybe it would be a nice feature if a placeable could be assigned somehow automaticly to COLLADA objects.
About inworld creation tools I think it's nice and useful to have some basic tools like 3d text, a pointer and maybe a basic sketching tool with line and circle features to draw some planes which could be used for web content or image display.
It could also be useful to have sort of a library of basic geometric shapes to use to sketch out something quickly in realtime collaborative sessions, with an option to group selected elements and to export those groups to a COLLADA or .obj file.
Happy new year to everyone in the group. Its great to see how the realxtend project progresses.
Some things that come to my mind to wish is about enhancing the COLLADA import by using zipped COLLADA files like the Khronos suggestion of .zae files and a drag and drop feature to upload them like it is in open wonderland.
The way how it works right now is allready great, but I think I wasn't the only one that tripped by the upload, before finding out that a placeable has to be assigned too.
Maybe it would be a nice feature if a placeable could be assigned somehow automaticly to COLLADA objects.
About inworld creation tools I think it's nice and useful to have some basic tools like 3d text, a pointer and maybe a basic sketching tool with line and circle features to draw some planes which could be used for web content or image display.
It could also be useful to have sort of a library of basic geometric shapes to use to sketch out something quickly in realtime collaborative sessions, with an option to group selected elements and to export those groups to a COLLADA or .obj file.
Peter C
Jan 9, 2013, 10:22:03 AM1/9/13
to real...@googlegroups.com
Just a few suggestions / things to note.
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.
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.
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.
Cheers,
Peter
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.
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.
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.
Cheers,
Peter
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Toni Alatalo
Jan 9, 2013, 1:05:24 PM1/9/13
to real...@googlegroups.com
On Wed, 2013-01-09 at 10:22 -0500, Peter C wrote:
> Just a few suggestions / things to note.
Thanks - quick comments:
> Just a few suggestions / things to note.
>
> 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
> 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.
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.
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
> 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.
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
Peter C.
Jan 9, 2013, 1:30:51 PM1/9/13
to real...@googlegroups.com
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
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,
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
resources that require you edit the engine source code at a low level to
add functionality needed for a script. My thoughts were to try to use
Tundra as a base to try to fix Torque's weaknesses, while allowing for
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
with better tutorials on extending realXtend (not just scripts, but
plug-ins as well). The documentation from Torque is really good compared
to Tundra, and Tundra is a pain to start developing for from an
outsider's prospective. Meshmoon alleviated some of the content creation
documentation issues, however for development of additional plug-ins, or
more general, non-Meshmoon specific documentation, realXtend is still
lacking big time. I'm still having issues getting DCC working for
realXtend, and I haven't been able to do much involving test scenes
because of it. The documentation for adding a new plug-in, such as a
terrain module, is almost non-existent. There are other irks such as not
having easy to access documentation telling what the shortcuts are for
the pop up windows easily accessible from Github or in a document
somewhere in the Git as well.
I think that the primary things that RealXtend could benefit from would
be better documentation of how to develop for it beyond basic scripting
and DCC, such as tutorials for plug-in/script development, content
creation, and general tutorials which take you through the whole process
of creating a basic game/scene that's actually playable and more
interesting than just walking around (something like Ludocraft Circus or
a basic FPS); and the ability to more easily create content. These
things would be the primary way to get ready to bring more people over.
Beyond that, better outreach and publicizing of the project itself would
bring more people in as well. The only reason I found out about
realXtend in the first place was because I found it by chance through
the opensim wiki. Having press releases about releases and the like go
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
probably help bring more people in. RealXtend is a good framework, even
if it needs some tune-ups, but it needs more publicity and documentation
in order to grow and get bigger.
>> Ludocraft made one report on this already ages ago, they�ll
>> todo items and feature wishes too but I don�t think it suits
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
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,
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
resources that require you edit the engine source code at a low level to
add functionality needed for a script. My thoughts were to try to use
Tundra as a base to try to fix Torque's weaknesses, while allowing for
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
with better tutorials on extending realXtend (not just scripts, but
plug-ins as well). The documentation from Torque is really good compared
to Tundra, and Tundra is a pain to start developing for from an
outsider's prospective. Meshmoon alleviated some of the content creation
documentation issues, however for development of additional plug-ins, or
more general, non-Meshmoon specific documentation, realXtend is still
lacking big time. I'm still having issues getting DCC working for
realXtend, and I haven't been able to do much involving test scenes
because of it. The documentation for adding a new plug-in, such as a
terrain module, is almost non-existent. There are other irks such as not
having easy to access documentation telling what the shortcuts are for
the pop up windows easily accessible from Github or in a document
somewhere in the Git as well.
I think that the primary things that RealXtend could benefit from would
be better documentation of how to develop for it beyond basic scripting
and DCC, such as tutorials for plug-in/script development, content
creation, and general tutorials which take you through the whole process
of creating a basic game/scene that's actually playable and more
interesting than just walking around (something like Ludocraft Circus or
a basic FPS); and the ability to more easily create content. These
things would be the primary way to get ready to bring more people over.
Beyond that, better outreach and publicizing of the project itself would
bring more people in as well. The only reason I found out about
realXtend in the first place was because I found it by chance through
the opensim wiki. Having press releases about releases and the like go
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
probably help bring more people in. RealXtend is a good framework, even
if it needs some tune-ups, but it needs more publicity and documentation
in order to grow and get bigger.
>> 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
>> suggestions, either here or privately.
>>
>> 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
>> 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
>> 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!
>> 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.
>>
Toni Alatalo
Jan 9, 2013, 1:42:04 PM1/9/13
to real...@googlegroups.com
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
> 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
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,
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
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
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
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
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
> >> 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
> >> suggestions, either here or privately.
> >>
> >> 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
> >> 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
> >> 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!
> >> 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.
> >>
Peter C.
Jan 9, 2013, 2:24:52 PM1/9/13
to real...@googlegroups.com
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.
>>>> Ludocraft made one report on this already ages ago, they�ll
>>>> todo items and feature wishes too but I don�t think it suits
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.
>>>> 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
>>>> suggestions, either here or privately.
>>>>
>>>> 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
>>>> 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
>>>> 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!
>>>> 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.
>>>>
Jonne Nauha
Jan 9, 2013, 4:11:02 PM1/9/13
to real...@googlegroups.com
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
Jonne Nauha
Adminotech developer
>>>> Ludocraft made one report on this already ages ago, they’ll
>>>> 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
>>>>
>
Peter C.
Jan 9, 2013, 4:55:38 PM1/9/13
to real...@googlegroups.com
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:
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.�
>>>> � � � � 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
to...@playsign.net
Jan 10, 2013, 3:15:42 AM1/10/13
to real...@googlegroups.com
A couple little hopefully clarifying points:
I think what Peter meant with porting and Jonne with rewriting is the same thing.. taking ideas and implementing them on Tundra, i.e. porting to Tundra. Possibly abstract logic code could be reused within some functionality, for example in a camera animation math code or game AI logic rules or so. Benefits of Tundra being reportedly nicer arch and code structure, ECs vs. using inheritance hierarchies for the functionalities etc .. the core mechanics on which the features would be rewritten. It sure is encouraging and nice that an outside evaluator who has studied sources of both softwares makes that proposal 😊
About reX scope & Tundra Core etc: certainly we are not changing the definition of Tundra core, fancy editors and asset libraries etc. are definitely not part of the core (as in the core APIs, ‘the purple box’, the non-optional parts of Tundra SDK) and at least if they are large or custom, not part of the SDK and the default distribution either.
In an extreme case, if we’d decide to pursue a complex e.g. a one-click-app-creator within realXtend, it could well be e.g. a separate project with an own repo and all .. for example an optional Tundra plugin which could be bundled in some ‘creator release’, but which would not be necessary in a minimal end user client used to visit scenes. A port of Ogitor to be a Tundra plugin would certainly fit in this category I think, as a fork tracking the original Ogitor repo perhaps.
I just want to keep it clear how realXtend assoc. activities and Tundra core & SDK scope can be different things, it is up to us to decide where we think cooperation and some common public effort would be most useful.
That said, in the meeting I found that shaders were one concrete content-centric topic which seems nice and simple, and which can help almost everyone to create more things easier. The current SuperShader and other bundled shaders for e.g. the parallel split shadows etc. are in all releases, are basically always assumed to be there, is ‘core’ in that sense (whereas technically they are more just arbitrary scene content) -- if there are clear needs for improvement in that department it could make a nice little project. Of course they don’t help anything alone, if no one knows how to create a new scene or app, but as one piece for the puzzle. One relieving point about shaders is that they are at least somewhat engine agnostic, AFAIK same GLSL can run in Ogre and WebGL and whatever other engine (well, at least when using opengl.. but that’s a different discussion).
I’d like the creation focused track to continue as planned, with Ludo and Spinningwire/ENER etc. art folks gathering requirements for their professional work etc., and Admino informing about your needs. BTW Jonne it was originally Tommi from Admino who said that new content examples and something to help content creation would be the most important thing for reX now 😊
But definitely docs and tutorials etc. are so important, obviously related to ease of creation too, that must be top priority. I don’t know yet how to organize that work but I think will talk with Kari, perhaps he has ideas how to get some funded doc project going. Last year I tried to get some university folks at the dept. of information processing sciences (software engineering etc) who work with people in the informatics department (library etc folks on the humanist side) to do some reX document work but haven’t heard anything back. Perhaps useful for long term, but for a quick fix we need something simpler .. a little project for some company and/or just doing more tutos and docs in our free time.
~Toni
to...@playsign.net
Jan 10, 2013, 11:45:27 AM1/10/13
to real...@googlegroups.com
Hi, just for info that I edited the notes from the meeting to be clearer, structured a bit and set headings for sections etc. - also added the note about focus on game dev which was discussed here.
Separated background discussion etc. from actual decisions more clearly.
~Toni
Nexii
Jan 10, 2013, 1:15:11 PM1/10/13
to real...@googlegroups.com, real...@googlegroups.com
Hi,
Been following this conversation with some interest as I am one of those people waiting until documentation (and fancy editors) catch up.
Recently came across this useful article on open source efforts for documentation and developer/user engagement: http://coding.smashingmagazine.com/2013/01/03/starting-open-source-project/
Hope it helps sharpen direction just as it has done to me.
Regards,
Nexii Malthus
Jonne Nauha
Jan 10, 2013, 2:17:25 PM1/10/13
to real...@googlegroups.com
We have done some more documentation for Meshmoon. It's not exactly realXtend Tundra but most of the things in the tutorial videos etc. are the same as you would do them with a basic Tundra.
Docs: http://doc.meshmoon.com/
Developer doxygen (applicable to Tundra): http://doc.meshmoon.com/doxygen/
Tutorial videos: http://www.youtube.com/user/Adminomedia
Just as a hint if you are looking into this now. Unfortunately I doubt we'll get anything concrete on rex documentation side in a while :I
Best regards,
Jonne Nauha
Adminotech developer
Jonne Nauha
Adminotech developer
Mark Malewski
Jan 10, 2013, 6:13:25 PM1/10/13
to real...@googlegroups.com
> 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.
When I look back at RealXtend back in the 2008 era, it was a great platform.
Nowadays, we are about 5+ years behind other technology.
If you look at platforms like CryEngine 3, which is now readily available (for free) for educational use, and just for academic learning.
It would be really nice to create an engine that is comparable (or even better than) CryEngine 3.
With all of the same exact features as CryEngine 3, and a nice sandbox editor.
Here would be my list of "most wanted" features:
1) Photo-realistic and destructible vegetation (that is able to move in the wind, and trees are able to be shot, destroyed, broken or burnt)
2) Destructible buildings and destructible environments
- You can shoot trees, shoot rocks, shoot buildings, shoot vehicles, etc. The vehicles can be damaged and destroyed, based on physics. Similar to CryEngine 3
4) Photo-realistic vehicles and vehicle physics (using Bullet Physics) that allows for destructible vehicles that have opening car doors, opening hoods, and are able to be damaged, and even destroyed (via crashes, or weapons damage, etc.)
5) Large "mega regions" (large maps) that can handle hundreds of concurrent users, and have "instant" handoffs between regions (aircraft can fly seamlessly between regions with zero lag)
6) Air-to-Air and Air-to-Ground combat and weapons systems.
6) Air-to-Air and Air-to-Ground combat and weapons systems.
7) Advanced Modular AI System (similar to CryEngine 3)
8) Photorealistic faces and characters (similar to CryEngine 3)
- Character Animation System
- Character Individualization System
- Parametric Skeletal Animation
- Procedural Motion Warping & High-End IK solutions
- Dedicated Facial Animation Editor
- Subsurface Scattering
9) Ability to edit/import assets and maps from CryEngine 3
- Able to use maps created in CryEngine 3 with ReX
(without modification)
10) Physics Hardware acceleration for BOTH Radeon 7970 and 7990 graphics cards and NVIDIA graphics cards (using OpenCL) that supports Bullet Physics hardware acceleration.
11) CPU/GPU Multi-core and high-end graphics card (OpenCL) support.
12) Design/modify the server so that regions that are empty (or are not being used) can be configured with a "timeout" feature that will shut down any empty or unused regions so that they don't use valuable system resources (RAM, CPU clock cycles, etc.) Add a "timeout" feature to the regions.ini file.
- Timeout = 0 (for regions that have timeout disabled)
- Timeout = 60 (for regions that shut down after being empty for sixty seconds).
- Timeout = 600 (for regions that shut down after being empty for ten minutes)
- Timeout = 1800 (for regions that shut down after being empty for a half hour)
- Timeout = 3600 (for regions that shut down after being empty for an hour)
13) Design "on-the-fly" region loading and unloading.
- Regions that are idle (and shut down) can be turned on and loaded (in realtime) so that large geographic areas (like a whole state or whole country) could be stored on one single server and the regions can be loaded (or pre-loaded) as an aircraft (or person) is getting close to a region crossing. Regions that are idle (with no users and have a "timeout" feature enabled with a configurable number of seconds before an empty region is shut down so that it doesn't use system resources).
Regions can be preloaded/loaded in near realtime, so that there are seamless region crossings between regions that are running and regions that are shut down. If a user is in a region, you can configure other nearby regions to pre-load so that seamless region crossings can happen.
This would allow for flight simulation and battlefield visualization and large maps (of the whole world) where users could fly an aircraft, or ride a train, or drive a vehicle around the whole world.
Design the game engine as a very very advanced "CryEngine 3" type game engine. With ALL of the features and speed of CryEngine 3.
> Games tend to be one of the biggest driving forces
> of technology.
Absolutely true.
Absolutely true.
If you design a very advanced open-source "CryEngine 3" capable engine, that is just as fast, and is even better (and more powerful) than CryEngine 3, it would benefit BOTH game developers (as a free and open-source development platform) as well as the academic community (which would use the platform for educational use and even for teaching 3D virtualization and game development)
-> Mark
Jonne Nauha
Jan 10, 2013, 6:27:36 PM1/10/13
to real...@googlegroups.com
I'm sorry Mark but that is a bit ridiculous, you just took it way over the top :) I guess a man can dream but lets think about it for a second:
Cryengine or anything comparable has been done with hundreds of developers over numerous years of development spending millons and millons of dollars on it. Unfortunately I don't think we will never have the funding nor the team to compete with billion dollar companies :) If you are looking for exactly the feature set that cryengine provides (you pretty much listed them), why not use it now (as you said there is a version out for free) instead of waiting for a open source thing? :)
Also in 2008 realXtend was not a "platform", it was a copied client to opensim/SL that tried to play catch up with the other opensim clients features. We never got even close and there was nothing revolutionary back then in realXtend tech other than maybe having meshes work :) Tundra is much more than just another opensim client, we can actually say its a open source virtual world platform nowadays with its own ideas and ideology how things should be built.
There is lots to do, but I doubt destructible vegetation and stuff will be first on the list. Lets keep it simple and do things that are actually useful for most use cases.
Best regards,
Jonne Nauha
Adminotech developer
Jonne Nauha
Adminotech developer
Reply all
Reply to author
Forward
0 new messages