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

Wed Aug 19 12:32:45 UTC 2015

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5629 bytes
Desc: not available
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150819/68489103/attachment.bin>