<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><tt>Thanks, Doug.</tt><tt> 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!<br>
<br>
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 -- </tt><tt><tt>entertainment, </tt>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.<br>
</tt><br>
On 8/19/2015 5:32 AM, Maxwell, Douglas CIV USARMY ARL (US) wrote:<br>
</div>
<blockquote
cite="mid:180878FAC40F8447ADED7BA2DE0775FD33D906E7@ugunhpso.easf.csd.disa.mil"
type="cite">
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev-bounces@opensimulator.org">opensim-dev-bounces@opensimulator.org</a> [<a class="moz-txt-link-freetext" href="mailto:opensim-dev-bounces@opensimulator.org">mailto:opensim-dev-bounces@opensimulator.org</a>] On Behalf Of Justin Clark-Casey
Sent: Tuesday, August 18, 2015 6:51 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a>
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] <a class="moz-txt-link-freetext" href="https://msdn.microsoft.com/en-us/library/ff926074.aspx">https://msdn.microsoft.com/en-us/library/ff926074.aspx</a>
On Thu, Aug 13, 2015 at 5:32 PM, Cinder Roxley <a class="moz-txt-link-rfc2396E" href="mailto:cinder@alchemyviewer.org"><cinder@alchemyviewer.org></a> wrote:
On August 13, 2015 at 8:14:30 AM, Maxwell, Douglas CIV USARMY ARL (US) (<a class="moz-txt-link-abbreviated" href="mailto:douglas.maxwell3.civ@mail.mil">douglas.maxwell3.civ@mail.mil</a>) 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
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<a class="moz-txt-link-freetext" href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
Classification: UNCLASSIFIED
Caveats: NONE
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<a class="moz-txt-link-freetext" href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>