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 On Fri, Jan 11, 2013 at 1:13 AM, Mark Malewski <mark.malew...@gmail.com>wrote: > *> 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. > * > > I completely agree. > > 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. > > Here: http://www.crydev.net/dm_eds/download_detail.php?id=4 > > 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. > > http://www.crytek.com/cryengine/cryengine3/overview > > 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 > > 3) Live Vegetation that is able to grow, and spread. (Flowers can > automatically bloom based on season/weather, seeds can spread based on > wind, vegetation can be planted and grown) > > 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. > > 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. > > 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 > > > > On Wed, Jan 9, 2013 at 9:22 AM, Peter C <th3fly...@gmail.com> wrote: > >> 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 >> >> t...@playsign.net 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 >>> >>> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> -- >> 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
