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: [email protected]
[mailto:[email protected]] On Behalf Of Justin Clark-Casey
Sent: Tuesday, August 18, 2015 6:51 AM
To: [email protected]
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 <[email protected]> wrote:
On August 13, 2015 at 8:14:30 AM, Maxwell, Douglas CIV USARMY ARL (US)
([email protected]) 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
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Classification: UNCLASSIFIED
Caveats: NONE
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
