[Opensim-dev] The Future of Open Simulator(?) (UNCLASSIFIED)

Wed Aug 19 14:37:10 UTC 2015

Thanks, Doug.Speaking both as an open source developer, as an academic 
and as a regular citizen, I really appreciate that you are going out of 
your way to make the code your lab develops matter and be available to 
others, now and in the future. That is the answer I was hoping to hear! 
As you say, way too many federally-funded projects have evaporated after 
serving some short-term purpose (like writing a paper or making a demo 
to upper management, for example), and that's just a waste. So kudos to 
you for exploring outside the box of comfort!

There's all sorts of software processes, and some are difficult to 
integrate. There's a range of options for co-existing, and hopefully 
we'll find one that works. Having a framework as the common core has 
worked very well for this project from early on, as pretty much every 
core developer that joined had their own vision about how to use this -- 
entertainment, education, research, urban planning, simulations, 
training... These are all very different usage scenarios that require 
different approaches in certain aspects of the design of these virtual 
environments. Our convergence towards the framework solution was not as 
much planned as it was a natural consequence of us needing a large 
engineering team to make our visions happen, and having no choice but to 
work together in spite of wanting to go in different directions.

On 8/19/2015 5:32 AM, Maxwell, Douglas CIV USARMY ARL (US) wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> I'm pleased to see the discussion stimulated thoughtful responses.  A number of you have PM'd me with similar questions, so I'll answer some of them here:
>
> 1.  Does the MOSES project want to manage Open Simulator?  No.  I have very specific training and education requirements that the MOSES prototype satisfies, but the Open Simulator development is quite broad and would need leadership that cares about issues such as entertainment and profit-motivated business models.
>
> 2.  Do you (Doug Maxwell) want to manage Open Simulator?  No.  It would be a conflict of interest given that I am a federal employee and my project responsibilities include funding the code modifications to the platform to achieve the mission S&T goals.
>
> 3.  Does the MOSE project want to become part of the Open Simulator Core Development team?  No.  As subjective, disorganized and chaotic as the dev code acceptance process seems to be, it is still your community.  Our code development culture is quite rigid and I fear our presence would be too disruptive.  We plan and schedule everything since funding is tied to the effort.  There's eight of us working on PhysX at the moment to meet the Sept deadline for testing and evaluation.
>
> 4.  Why do you care about whether or not the Open Simulator developers accept MOSES code contributions?  I have seen many examples of military funded science and technology projects not emerge from the labs.  They serve a limited purpose and are retired when complete.  The work we are doing with MOSES will provide valuable guidance to the Army acquisition community when specifying requirements for the next generation of infantry soldier skills trainers.  We also are making usage discoveries in the field that guide our interface design decisions.  My job is not to create operational training systems, but rather to investigate gaps in our training and find solutions.  I don't want to see the MOSES prototype forgotten after it is retired at the logical end of our investigation.  The code we are pouring into the Open Simulator to address common deficiencies in performance across all virtual world platforms should be re-used to benefit the community as a whole.
>
> 5.  Are we holding any code back?  No.  I've made it clear to all the MOSES developers that there is a clear delineation between the simulator and the content it serves.  This makes life easier on all fronts.  By hanging our code off the GitHub, we can collaborate with other Gov't researcher (civilian and military) quite efficiently.  We've created MOSES-in-a-Box for the agencies who cannot expose their networks to the open Internet, but can still participate internally in MOSES related activities.
>
> 6.  Are we holding any content back?  Yes.  Lots.  We provide sanitized examples of usage through our web site with some OAR downloads, but any scenario that has accurate information in it is not for public consumption.
>
> 7.  What will MOSES work on after PhysX?  Our profiling activities discovered the Open Simulator was spending most of its time in the Physics, Client Manager, and Script Engines.  BulletSim was low hanging fruit for us since it is single threaded and we are genuinely curious to see if GPU acceleration through PhysX will have a meaningful impact on simulator performance.  Sean Mondesire and Glenn Martin are also working on a distributed PhysX server that is separate from Open Simulator that we hope will have major performance gains.  After PhysX, we will make the decision to either tackle the client manager or the script engine.  Much of this is derivative from the DSG work done in 2013, however instead of middle-ware brokering synchronization of multiple Open Simulator instances with identical databases - this is truly breaking up the engine into major constituent pieces and distributing them across a network to spread load.
>
> v/r -doug
>
> Dr. Douglas Maxwell
> Science and Technology Manager
> Virtual World Strategic Applications
> U.S. Army Research Lab
> Simulation & Training Technology Center (STTC)
> (c) (407) 242-0209
>
>
> -----Original Message-----
> From: opensim-dev-bounces at opensimulator.org [mailto:opensim-dev-bounces at opensimulator.org] On Behalf Of Justin Clark-Casey
> Sent: Tuesday, August 18, 2015 6:51 AM
> To: opensim-dev at opensimulator.org
> Subject: Re: [Opensim-dev] The Future of Open Simulator(?) (UNCLASSIFIED)
>
> On point 2, the coding standards are pretty much the C# guidelines at [1] (I thought there used to be a longer doc but can't find it on a quick google).
>
>
> On point 3, this is very true.  It's a problem of the codebase having grown organically with many different developers of varying skill levels.
>
>
> During the 2013 and 2014 OSCC conferences I spent a lot of time on scalability but much of this was ad-hoc fixes or measurement tooling.  The advantage of being extremely thread happy is that if one thread gets blocked (e.g. waiting on I/O) then this won't halt other threads (assuming it isn't in a locked region).  But the disadvantage is unpredictable performance and overhead though I don't know how much.
>
>
> I believe any VW engine eventually need something like an OS scheduler to control work performance and make sure that CPU utilization is efficient and handles degradation gracefully at 100% utilization.  However, that's an extremely tough problem and I'm not sure it's even possible in a managed language.
>
>
> On point 4, I believe any future is gradual evolution.  The investment required for radical change is simply too high.  Perhaps it would be easier if some way can be found to break apart monolithic VW systems but then monoliths have continued to win in the operating system space (Linux vs micro-kernels for instance) and I think operating systems have many similarities with user script executing virtual worlds.
>
>
> -- Justin
>
>
> -- Justin
>
>
> [1] https://msdn.microsoft.com/en-us/library/ff926074.aspx
>
>
> On Thu, Aug 13, 2015 at 5:32 PM, Cinder Roxley <cinder at alchemyviewer.org> wrote:
>
>
> 	On August 13, 2015 at 8:14:30 AM, Maxwell, Douglas CIV USARMY ARL (US) (douglas.maxwell3.civ at mail.mil) wrote:
>
> 		
> 		Classification: UNCLASSIFIED
> 		Caveats: NONE
> 		
> 		Can someone explain to me why the core developers insist on control of the
> 		code, but refuse to manage the project? I ask again: what are your plans for
> 		the future of Open Simulator? It's ok to say you don't have any, let's make
> 		some!
> 		
> 		I'll throw out some ideas based on the MOSES goals and objectives:
> 		
> 		1) Scale limitations lifted. We need a system that is governed by its
> 		available hardware and network resources, not bound by software limits.
> 		
> 		2) Let's create clear definitions of "stability".
> 		
> 		3) Clear and up-to-date API documentation.
> 		
> 		4) Clear and up-to-date OS deployment guidance under numerous typical network
> 		topologies.
> 		
> 		5) Bug identification & reduction.
> 		
> 		6) Efficient ray tracing. Useful for simulation of sensors as well as
> 		naturalized bot interactions.
> 		
> 		7) N-body physics. Would be nice to have vehicles that can follow terrain
> 		and not look like Star Wars land speeders. Would also be nice to have more
> 		natural avatar movement rather than the rigid animations we use now.
> 		
> 		What are yours? Anyone?
> 		
> 		v/r -doug
>
> 	This can be considered my “wish list” as I don’t really have a say in what happens, but I’m willing to put in a fair share of work in seeing that it can be done if others agree these are desirable targets:
>
> 	1) Restating what Doug has mentioned, Clear and up-to-date API documentation. This hinders contributors, myself included, from working on things and leads to a lot of frustration and disappointed from well-intentioned folks.
>
> 	2) A coding standard that defines and formalizes the style of code used throughout the codebase and is adhered to and enforced and should be pointed to often and regularly for contributions. Good code is easy to read and manageable. A formal coding standard is a good step in that direction.
>
> 	3) OpenSim is a thread monster. There doesn’t seem to be any sort of approach to how threading is handled. This I think would fall under Doug’s criteria for #1.
>
> 	4) I think it’s time to hop off the fence and decide whether to maintain the Second Life protocol compatibility, (Which, let’s be honest, is pretty lacking. There’s a lot missing post-2010.) or to break new ground. Linden Lab has apparently made their decision regarding that. There are viewer developers out there willing to work with OpenSimulator is doing this. I am one of them. I just can’t be in IRC all the time, but I want to do this with you guys and I know there are others out there willing to put in the work to build clients to connect to new and better worlds with sensible protocols.
>
> 	Please don’t take any of this as criticism as it is not meant as such. I appreciate all the work that everyone on this project and who is affiliated with it does.
>
> 	
> 	--
> 	Cinder Roxley
> 	Sent with Airmail
>
> 	_______________________________________________
> 	Opensim-dev mailing list
> 	Opensim-dev at opensimulator.org
> 	http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> 	
> 	
>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150819/356895e6/attachment-0001.html>