Re: Opensim-dev Digest, Vol 13, Issue 14

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Opensim-dev Digest, Vol 13, Issue 14

steve l
Hi!

Thank you everyone for your answers. It got me thinking again, and generally that is dangerous!

Is part of our problem in that OS was designed originally quite a few years ago and is still suffering from code that was written to satisfy the needs of the old servers we had at the time. Is Legacy code holding us back?

Is OS actually still running 32 bit code in a 64 bit world? Might that be our main bottleneck in getting frame rates up and it being able to handle the new demands we put on it?

Maybe it is time to go through OpenSim bit by bit and see what we can update and what we just don't need anymore. From what I have been hearing from many sources there are a lot of little things that are really critical issues from handling of the database to interactions and timings in Physics to networking issues and the need to update to more stout components like the internal web server.

Everyone will probably want me to blow me out of the water screaming and yelling at me, but maybe it is time to take a hard look at what needs to be done with our base system to bring it kicking and screaming into the second decade of the 21st century!

I think a lot of the time we are just patching patches. We know how well that works on car tires! Maybe it is time to put on some new tires and get rid of some of our issues once and for all!

Steve LaVigne

On Wed, Apr 15, 2015 at 7:33 AM, <[hidden email]> wrote:
Send Opensim-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opensim-dev digest..."


Today's Topics:

   1. Re: New MOSES Physics Video (UNCLASSIFIED)
      (Maxwell, Douglas CIV USARMY ARL (US))
   2. Re: Opensim-dev Digest, Vol 13, Issue 13 (steve l)


----------------------------------------------------------------------

Message: 1
Date: Wed, 15 Apr 2015 14:20:55 +0000
From: "Maxwell, Douglas CIV USARMY ARL (US)"
        <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: [Opensim-dev] New MOSES Physics Video (UNCLASSIFIED)
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Classification: UNCLASSIFIED
Caveats: NONE

1.  This is an excellent point that illustrates just how wickedly complex our problem is.  The short answer is "yes", we could do it locally.  However, the distribution of the shared experience is a hard requirement and the final state of the bricks must be accurately portrayed to all client connections.  One way to handle this is to treat this like a state machine and make sure all clients have precisely the same start conditions and then apply the same physics calculations.  Theoretically, we would have the same end conditions.  Afterward, we could queue the state changes of all the object and then have an arbitration process at the server make sure everything is actually at the same global location and orientation.

This is a complex issue as it is contrary to the current world state model and would require the server to temporarily relinquish control of prims during the physics action, then take it back after steady state.

3.  Our PhysX work is simply to ensure the physics calculations we need in the 83ms interval is actually completed and not dropped.  It is address any "rubber banding" effects you see.  It should also address jitter.  It is a balance between update rate, network saturation, and QoS.

4.  The DSG middleware approach gave us many insights into how a truly distributed simulator could work.  That was extremely valuable work for us and we were privileged to have excellent collaborators in Intel and a strong community of MOSES users willing to help us test.

v/r -douglas

Douglas Maxwell, MSME
Science and Technology Manager
Virtual World Strategic Applications
U.S. Army Research Lab
Simulation & Training Technology Center (STTC)
(c) <a href="tel:%28407%29%20242-0209" value="+14072420209">(407) 242-0209



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Mister Blue
Sent: Wednesday, April 15, 2015 12:21 AM
To: opensim-dev
Subject: Re: [Opensim-dev] New MOSES Physics Video

1. Is the explosion of blocks or prims something that the viewer can handle? Or is this too tricky to make happen with the wide variations of machine running viewers and even more so that soon the viewer will run in a web browser?
It is something a viewer could do but I don't know what mechanism could be used in the existing viewer.


2. Is there a way to make the explosion an overlay streaming event that runs over the current screen? - Just a crazy idea.... I am thinking of this more on a browser-viewer as that needs to run on devices that would have issues processing all that...
In interesting idea but, again, would be viewer modifications.


3. Is it possible to make OS Physics run faster than 11FPS?
Yes. The default configuration is for the simulator heartbeat time to be 11FPS and for the physics engine to be in sync. You can change the simulator heartbeat time but there are some known problems with that (too many assumptions in some places). If you run BulletSim on its own thread, you can speed up BulletSim but that would just make more updates.


4. It seems that the number of avatars exponentially changes the workload here. Maybe a graphics server could be designed as a sub service to handle that type of load, maybe running on a GPU instead of a CPU? It just seems to me that with all the other things that the region server has to do, offloading some of the heavy lifting would be a good thing. Maybe it is time to think of an OS "Pro" level of setup that separates the workload a bit more would be a good idea

That was the design of DSG. For client connections, the simulator fed on client manager who multiplied the connection to multiple viewers. So you could have a simulator feeding 10 client managers who were each feeding 30 viewers for a total of 300 connections. DSG also run script and physics servers to off load the central server from the computation from those operations.


== mb

On Tue, Apr 14, 2015 at 1:49 PM, Dahlia Trimble <[hidden email]> wrote:


        I believe there is a means in the LLUDP protocol to stuff many updates for many objects into a single packet, though I'm not sure OpenSimulator is smart enough to do it in your simulation. It may be a way to improve networking performance quite a bit when may physical objects change velocity during the same simulation frame.


        On Tue, Apr 14, 2015 at 1:44 PM, steve l <[hidden email]> wrote:


                Hi!


                Robert- Thanks for the answer and the thought you put into it!


                So I am going to play dummy (Not far from the truth!) here. This means that we need to do re-writing on several parts of OS to speed things up and eliminate bottlenecks. a couple of questions then.


                1. Is the explosion of blocks or prims something that the viewer can handle? Or is this too tricky to make happen with the wide variations of machine running viewers and even more so that soon the viewer will run in a web browser?


                2. Is there a way to make the explosion an overlay streaming event that runs over the current screen? - Just a crazy idea.... I am thinking of this more on a browser-viewer as that needs to run on devices that would have issues processing all that...


                3. Is it possible to make OS Physics run faster than 11FPS?


                4. It seems that the number of avatars exponentially changes the workload here. Maybe a graphics server could be designed as a sub service to handle that type of load, maybe running on a GPU instead of a CPU? It just seems to me that with all the other things that the region server has to do, offloading some of the heavy lifting would be a good thing. Maybe it is time to think of an OS "Pro" level of setup that separates the workload a bit more would be a good idea.


                These things always get me thinking...!


                Steve LaVigne

                A Dimension Beyond, Inc.

                www.adimensionbeyond.com


                On Tue, Apr 14, 2015 at 10:45 AM, Adams, Robert <[hidden email]> wrote:


                        I don?t think the only problem is finding a physics engine that can handle 240 moving objects. Another is optimizing the updates from the physics engine.



                        Think of the whole pipeline: the physics engine computes interactions and new locations/rotations for each object. That position update is sent to the simulator. The simulator updates the object data structures and sets an update flag. The location/position update is noticed and an update packet[1] is created and placed in output queues for each viewer. At some time, the packet is transmitted to each viewer.



                        The update processing time can easily be more than the physics engine time.



                        The OpenSimulator physics engines are run 11 times a second so they generate 11 position updates a second for each moving object. So, even an efficient physics engine will generate (240 * 11) updates per second which then turn into (240 * 11 * numberOfAvatars) packets sent per second.



                        There are many optimizations possible in this chain.



                        -- mb



                        [1] This is technically wrong for the current version of OpenSimulator. For the technically inclined, an ?update needed? packet is put in the output queue and the actual packet to transmit is created when it is time to send the update. This is done because the update output packet queue can get long and the position/location information can be stale if multiple updates are in the queue. Only one ?update needed? packet is put in the queue and the current object location/rotation is put in the transmitted packet at the time of transmission.



                        From: [hidden email] [mailto:[hidden email]] On Behalf Of steve l
                        Sent: Tuesday, April 14, 2015 8:09 AM
                        To: Michael Emory Cerquoni
                        Cc: [hidden email]; [hidden email]
                        Subject: Re: [Opensim-dev] New MOSES Physics Video



                        Hi!

                        An excellent video on the physics of exploding grenades and the wall.  On the OS Dev list Mister Blue has an excellent observation that the server crashes are due to the extreme amount of changes that have to be sent to every avatar. His idea of a client side solution might just be a good one. In the end is there any way that OpenSim can handle more events than that in it's present form? Is there any physics engine that can handle 240 moving scripted objects moving at once without lag?

                        If we could get OS to the point that it would handle this load easily, we would have all our load issues solved!

                        Steve LaVigne



                        On Tue, Apr 14, 2015 at 6:33 AM, Michael Emory Cerquoni <[hidden email]> wrote:

                        Could these test scripts be shared so testing against other engines can occur as well, I would be interested to see how this same test goes against ODE and BulletSim as well.



                        On Tue, Apr 14, 2015 at 8:18 AM, Maxwell, Douglas CIV USARMY ARL (US) <[hidden email]> wrote:

                                Good Morning, as you all know the MOSES developers are working on PhysX integration into the Open Simulator to support functionality currently not possible in the platform.  We are a methodical group and a couple months ago I asked one of our interns to work with the developers to create a series of baseline physics behavior case studies.  The first case study is a destructible wall caused by an explosive charge.  This wall is composed of blocks that are tested at a high density and a low density to simulate different destruction effects.



                                The goal here is to eventually have all of the prims in the sim loaded with the scripts needed to react to any type of random explosive charge set by the participants in the training scenario.



                                The video can be found below:



                                https://youtu.be/jSofWcwWi7g <blockedhttps://youtu.be/jSofWcwWi7g>



                                Your feedback is welcome.



                                Observations:

                                1)  Current limitations of the open simulator prevent us from expanding the tests beyond a simple wall.

                                2)  The scripts exercise the engine well and expose limitations between the sim frame rate and the physics frame rate.

                                3)  It is easy to crash the sim with this demonstration, especially if more than a handful of people are present (more than 3-4 client connections).



                                Douglas Maxwell, MSME
                                Science and Technology Manager
                                Virtual World Strategic Applications
                                U.S. Army Research Lab

                                Human Research & Engineering Directorate
                                Simulation & Training Technology Center
                                (c) <a href="tel:%28407%29%20242-0209" value="+14072420209">(407) 242-0209 <blockedtel:%28407%29%20242-0209>



                                _______________________________________________
                                Opensim-dev mailing list
                                [hidden email]
                                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>




                        --

                        Michael Emory Cerquoni





                _______________________________________________
                Opensim-dev mailing list
                [hidden email]
                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>





        _______________________________________________
        Opensim-dev mailing list
        [hidden email]
        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <blockedhttp://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/20150415/878f7ce1/attachment-0001.bin>

------------------------------

Message: 2
Date: Wed, 15 Apr 2015 07:33:11 -0700
From: steve l <[hidden email]>
To: [hidden email]
Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 13, Issue 13
Message-ID:
        <CAB38sFg2m8qtfeHdFCQcuavpBq5tVDQ609MJJ67bDCiT2Mh=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Thanks Ai!

It is interesting that we were doing this apparently really well 10 years
ago! Apparently in so many ways we have to reinvent the wheel over and over!

Maybe we need to get ahold of these guys and see if they will share...

Steve LaVigne
A Dimension Beyond, Inc.
www.adimensionbeyond.com

On Wed, Apr 15, 2015 at 5:00 AM, <[hidden email]>
wrote:

> Send Opensim-dev mailing list submissions to
>         [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> or, via email, send a message with subject or body 'help' to
>         [hidden email]
>
> You can reach the person managing the list at
>         [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Opensim-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: New MOSES Physics Video (Ai Austin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Apr 2015 09:59:23 +0100
> From: Ai Austin <[hidden email]>
> To: [hidden email]
> Subject: Re: [Opensim-dev] New MOSES Physics Video
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> I saw the suggestion that explosion "physical" effects like this
> might be dealt with locally (e.g. in the same was as particle visual
> effects) in each viewer and not as a shared phenomenon where the
> position of all the parts are updated in everyone's viewer.
>
> Snow and lighting visual effects often can be approximated and
> everyone has roughly the same sort of shared experience, modulo the
> allowable and supportable  graphical quality in each viewer..
>
> I am reminded though of an exercise I took part in using the Forterra
> OLIVE when that was still being actively developed (I think it got
> sold to SAIC and I have not heard much aboit it since)...  it was a
> training exercise for military staff manning a checkpoint, and I was
> an observer through my avatar.  The military folks being trained were
> to watch fro suspicious activity, but also treat all people at the
> checkpoint well... and also to deal with the aftermath of an attack..
> rescue helicopter coming in with dust clouds from the ground and
> all... it was very realistic.  And I was very surprised, even though
> my avatar was partially protected from the checkpoint area by a solid
> wall, that an explosion injured me... the pieces flying hiring my arm
> and me being rendered unconscious!  Viewer blurring over and me being
> almost out of it.
>
> This is an example of the use of virtual worlds where the shared
> experience of what debris from an explosion goes and who it hits and
> when is necessary.  And I think may be typical of the sort of thing
> MOSES is seeking to achieve for realistic simulated
> training.  Interestingly Forterra OLIVE was itself originally
> developed on a project for the US Army also more than a decade ago.
>
> Clearly there needs to be some consideration of the granularity of
> physics and position updates across all users that are present in the
> area and a consideration of how many parts of an exploding  object
> can be made physical and updates sent and at what rate.  This could
> be a simply enormous quantity of data and updates as others have
> pointed out... so its not surprising that more avatars leads to
> slower performance.  Crashes nonetheless indicates something that is amiss.
>
>
>
> ------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
> End of Opensim-dev Digest, Vol 13, Issue 13
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/271cbab9/attachment.html>

------------------------------

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


End of Opensim-dev Digest, Vol 13, Issue 14
*******************************************


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Opensim-dev Digest, Vol 13, Issue 14

Frank Nichols
Well, i think it is reasonable to expect that a design that is 10 years old to not be state of the art.

It goes further, OS tries hard to remain compatible with SL, while even Linden Labs has given up on the old design.

The problem is both the server and the clients. The amount of work to morph them into state of the art design/implementations is enormous, to say the least... And the work is being done by mostly volunteers, some of which have vested commercial interests in the design not varying much from the SL standard.

Bottom line i think is what we have is fantastic considering what we are expected to pay for it. And just to be fair, do you financially support any/all of the developers? I do.



Sent from my iPad Air 2

On Apr 15, 2015, at 2:03 PM, steve l <[hidden email]> wrote:

Hi!

Thank you everyone for your answers. It got me thinking again, and generally that is dangerous!

Is part of our problem in that OS was designed originally quite a few years ago and is still suffering from code that was written to satisfy the needs of the old servers we had at the time. Is Legacy code holding us back?

Is OS actually still running 32 bit code in a 64 bit world? Might that be our main bottleneck in getting frame rates up and it being able to handle the new demands we put on it?

Maybe it is time to go through OpenSim bit by bit and see what we can update and what we just don't need anymore. From what I have been hearing from many sources there are a lot of little things that are really critical issues from handling of the database to interactions and timings in Physics to networking issues and the need to update to more stout components like the internal web server.

Everyone will probably want me to blow me out of the water screaming and yelling at me, but maybe it is time to take a hard look at what needs to be done with our base system to bring it kicking and screaming into the second decade of the 21st century!

I think a lot of the time we are just patching patches. We know how well that works on car tires! Maybe it is time to put on some new tires and get rid of some of our issues once and for all!

Steve LaVigne

On Wed, Apr 15, 2015 at 7:33 AM, <[hidden email]> wrote:
Send Opensim-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opensim-dev digest..."


Today's Topics:

   1. Re: New MOSES Physics Video (UNCLASSIFIED)
      (Maxwell, Douglas CIV USARMY ARL (US))
   2. Re: Opensim-dev Digest, Vol 13, Issue 13 (steve l)


----------------------------------------------------------------------

Message: 1
Date: Wed, 15 Apr 2015 14:20:55 +0000
From: "Maxwell, Douglas CIV USARMY ARL (US)"
        <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: [Opensim-dev] New MOSES Physics Video (UNCLASSIFIED)
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Classification: UNCLASSIFIED
Caveats: NONE

1.  This is an excellent point that illustrates just how wickedly complex our problem is.  The short answer is "yes", we could do it locally.  However, the distribution of the shared experience is a hard requirement and the final state of the bricks must be accurately portrayed to all client connections.  One way to handle this is to treat this like a state machine and make sure all clients have precisely the same start conditions and then apply the same physics calculations.  Theoretically, we would have the same end conditions.  Afterward, we could queue the state changes of all the object and then have an arbitration process at the server make sure everything is actually at the same global location and orientation.

This is a complex issue as it is contrary to the current world state model and would require the server to temporarily relinquish control of prims during the physics action, then take it back after steady state.

3.  Our PhysX work is simply to ensure the physics calculations we need in the 83ms interval is actually completed and not dropped.  It is address any "rubber banding" effects you see.  It should also address jitter.  It is a balance between update rate, network saturation, and QoS.

4.  The DSG middleware approach gave us many insights into how a truly distributed simulator could work.  That was extremely valuable work for us and we were privileged to have excellent collaborators in Intel and a strong community of MOSES users willing to help us test.

v/r -douglas

Douglas Maxwell, MSME
Science and Technology Manager
Virtual World Strategic Applications
U.S. Army Research Lab
Simulation & Training Technology Center (STTC)
(c) <a href="tel:%28407%29%20242-0209" value="+14072420209">(407) 242-0209



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Mister Blue
Sent: Wednesday, April 15, 2015 12:21 AM
To: opensim-dev
Subject: Re: [Opensim-dev] New MOSES Physics Video

1. Is the explosion of blocks or prims something that the viewer can handle? Or is this too tricky to make happen with the wide variations of machine running viewers and even more so that soon the viewer will run in a web browser?
It is something a viewer could do but I don't know what mechanism could be used in the existing viewer.


2. Is there a way to make the explosion an overlay streaming event that runs over the current screen? - Just a crazy idea.... I am thinking of this more on a browser-viewer as that needs to run on devices that would have issues processing all that...
In interesting idea but, again, would be viewer modifications.


3. Is it possible to make OS Physics run faster than 11FPS?
Yes. The default configuration is for the simulator heartbeat time to be 11FPS and for the physics engine to be in sync. You can change the simulator heartbeat time but there are some known problems with that (too many assumptions in some places). If you run BulletSim on its own thread, you can speed up BulletSim but that would just make more updates.


4. It seems that the number of avatars exponentially changes the workload here. Maybe a graphics server could be designed as a sub service to handle that type of load, maybe running on a GPU instead of a CPU? It just seems to me that with all the other things that the region server has to do, offloading some of the heavy lifting would be a good thing. Maybe it is time to think of an OS "Pro" level of setup that separates the workload a bit more would be a good idea

That was the design of DSG. For client connections, the simulator fed on client manager who multiplied the connection to multiple viewers. So you could have a simulator feeding 10 client managers who were each feeding 30 viewers for a total of 300 connections. DSG also run script and physics servers to off load the central server from the computation from those operations.


== mb

On Tue, Apr 14, 2015 at 1:49 PM, Dahlia Trimble <[hidden email]> wrote:


        I believe there is a means in the LLUDP protocol to stuff many updates for many objects into a single packet, though I'm not sure OpenSimulator is smart enough to do it in your simulation. It may be a way to improve networking performance quite a bit when may physical objects change velocity during the same simulation frame.


        On Tue, Apr 14, 2015 at 1:44 PM, steve l <[hidden email]> wrote:


                Hi!


                Robert- Thanks for the answer and the thought you put into it!


                So I am going to play dummy (Not far from the truth!) here. This means that we need to do re-writing on several parts of OS to speed things up and eliminate bottlenecks. a couple of questions then.


                1. Is the explosion of blocks or prims something that the viewer can handle? Or is this too tricky to make happen with the wide variations of machine running viewers and even more so that soon the viewer will run in a web browser?


                2. Is there a way to make the explosion an overlay streaming event that runs over the current screen? - Just a crazy idea.... I am thinking of this more on a browser-viewer as that needs to run on devices that would have issues processing all that...


                3. Is it possible to make OS Physics run faster than 11FPS?


                4. It seems that the number of avatars exponentially changes the workload here. Maybe a graphics server could be designed as a sub service to handle that type of load, maybe running on a GPU instead of a CPU? It just seems to me that with all the other things that the region server has to do, offloading some of the heavy lifting would be a good thing. Maybe it is time to think of an OS "Pro" level of setup that separates the workload a bit more would be a good idea.


                These things always get me thinking...!


                Steve LaVigne

                A Dimension Beyond, Inc.

                www.adimensionbeyond.com


                On Tue, Apr 14, 2015 at 10:45 AM, Adams, Robert <[hidden email]> wrote:


                        I don?t think the only problem is finding a physics engine that can handle 240 moving objects. Another is optimizing the updates from the physics engine.



                        Think of the whole pipeline: the physics engine computes interactions and new locations/rotations for each object. That position update is sent to the simulator. The simulator updates the object data structures and sets an update flag. The location/position update is noticed and an update packet[1] is created and placed in output queues for each viewer. At some time, the packet is transmitted to each viewer.



                        The update processing time can easily be more than the physics engine time.



                        The OpenSimulator physics engines are run 11 times a second so they generate 11 position updates a second for each moving object. So, even an efficient physics engine will generate (240 * 11) updates per second which then turn into (240 * 11 * numberOfAvatars) packets sent per second.



                        There are many optimizations possible in this chain.



                        -- mb



                        [1] This is technically wrong for the current version of OpenSimulator. For the technically inclined, an ?update needed? packet is put in the output queue and the actual packet to transmit is created when it is time to send the update. This is done because the update output packet queue can get long and the position/location information can be stale if multiple updates are in the queue. Only one ?update needed? packet is put in the queue and the current object location/rotation is put in the transmitted packet at the time of transmission.



                        From: [hidden email] [mailto:[hidden email]] On Behalf Of steve l
                        Sent: Tuesday, April 14, 2015 8:09 AM
                        To: Michael Emory Cerquoni
                        Cc: [hidden email]; [hidden email]
                        Subject: Re: [Opensim-dev] New MOSES Physics Video



                        Hi!

                        An excellent video on the physics of exploding grenades and the wall.  On the OS Dev list Mister Blue has an excellent observation that the server crashes are due to the extreme amount of changes that have to be sent to every avatar. His idea of a client side solution might just be a good one. In the end is there any way that OpenSim can handle more events than that in it's present form? Is there any physics engine that can handle 240 moving scripted objects moving at once without lag?

                        If we could get OS to the point that it would handle this load easily, we would have all our load issues solved!

                        Steve LaVigne



                        On Tue, Apr 14, 2015 at 6:33 AM, Michael Emory Cerquoni <[hidden email]> wrote:

                        Could these test scripts be shared so testing against other engines can occur as well, I would be interested to see how this same test goes against ODE and BulletSim as well.



                        On Tue, Apr 14, 2015 at 8:18 AM, Maxwell, Douglas CIV USARMY ARL (US) <[hidden email]> wrote:

                                Good Morning, as you all know the MOSES developers are working on PhysX integration into the Open Simulator to support functionality currently not possible in the platform.  We are a methodical group and a couple months ago I asked one of our interns to work with the developers to create a series of baseline physics behavior case studies.  The first case study is a destructible wall caused by an explosive charge.  This wall is composed of blocks that are tested at a high density and a low density to simulate different destruction effects.



                                The goal here is to eventually have all of the prims in the sim loaded with the scripts needed to react to any type of random explosive charge set by the participants in the training scenario.



                                The video can be found below:



                                https://youtu.be/jSofWcwWi7g <blockedhttps://youtu.be/jSofWcwWi7g>



                                Your feedback is welcome.



                                Observations:

                                1)  Current limitations of the open simulator prevent us from expanding the tests beyond a simple wall.

                                2)  The scripts exercise the engine well and expose limitations between the sim frame rate and the physics frame rate.

                                3)  It is easy to crash the sim with this demonstration, especially if more than a handful of people are present (more than 3-4 client connections).



                                Douglas Maxwell, MSME
                                Science and Technology Manager
                                Virtual World Strategic Applications
                                U.S. Army Research Lab

                                Human Research & Engineering Directorate
                                Simulation & Training Technology Center
                                (c) <a href="tel:%28407%29%20242-0209" value="+14072420209">(407) 242-0209 <blockedtel:%28407%29%20242-0209>



                                _______________________________________________
                                Opensim-dev mailing list
                                [hidden email]
                                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>




                        --

                        Michael Emory Cerquoni





                _______________________________________________
                Opensim-dev mailing list
                [hidden email]
                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>





        _______________________________________________
        Opensim-dev mailing list
        [hidden email]
        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <blockedhttp://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/20150415/878f7ce1/attachment-0001.bin>

------------------------------

Message: 2
Date: Wed, 15 Apr 2015 07:33:11 -0700
From: steve l <[hidden email]>
To: [hidden email]
Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 13, Issue 13
Message-ID:
        <CAB38sFg2m8qtfeHdFCQcuavpBq5tVDQ609MJJ67bDCiT2Mh=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Thanks Ai!

It is interesting that we were doing this apparently really well 10 years
ago! Apparently in so many ways we have to reinvent the wheel over and over!

Maybe we need to get ahold of these guys and see if they will share...

Steve LaVigne
A Dimension Beyond, Inc.
www.adimensionbeyond.com

On Wed, Apr 15, 2015 at 5:00 AM, <[hidden email]>
wrote:

> Send Opensim-dev mailing list submissions to
>         [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> or, via email, send a message with subject or body 'help' to
>         [hidden email]
>
> You can reach the person managing the list at
>         [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Opensim-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: New MOSES Physics Video (Ai Austin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Apr 2015 09:59:23 +0100
> From: Ai Austin <[hidden email]>
> To: [hidden email]
> Subject: Re: [Opensim-dev] New MOSES Physics Video
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> I saw the suggestion that explosion "physical" effects like this
> might be dealt with locally (e.g. in the same was as particle visual
> effects) in each viewer and not as a shared phenomenon where the
> position of all the parts are updated in everyone's viewer.
>
> Snow and lighting visual effects often can be approximated and
> everyone has roughly the same sort of shared experience, modulo the
> allowable and supportable  graphical quality in each viewer..
>
> I am reminded though of an exercise I took part in using the Forterra
> OLIVE when that was still being actively developed (I think it got
> sold to SAIC and I have not heard much aboit it since)...  it was a
> training exercise for military staff manning a checkpoint, and I was
> an observer through my avatar.  The military folks being trained were
> to watch fro suspicious activity, but also treat all people at the
> checkpoint well... and also to deal with the aftermath of an attack..
> rescue helicopter coming in with dust clouds from the ground and
> all... it was very realistic.  And I was very surprised, even though
> my avatar was partially protected from the checkpoint area by a solid
> wall, that an explosion injured me... the pieces flying hiring my arm
> and me being rendered unconscious!  Viewer blurring over and me being
> almost out of it.
>
> This is an example of the use of virtual worlds where the shared
> experience of what debris from an explosion goes and who it hits and
> when is necessary.  And I think may be typical of the sort of thing
> MOSES is seeking to achieve for realistic simulated
> training.  Interestingly Forterra OLIVE was itself originally
> developed on a project for the US Army also more than a decade ago.
>
> Clearly there needs to be some consideration of the granularity of
> physics and position updates across all users that are present in the
> area and a consideration of how many parts of an exploding  object
> can be made physical and updates sent and at what rate.  This could
> be a simply enormous quantity of data and updates as others have
> pointed out... so its not surprising that more avatars leads to
> slower performance.  Crashes nonetheless indicates something that is amiss.
>
>
>
> ------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
> End of Opensim-dev Digest, Vol 13, Issue 13
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/271cbab9/attachment.html>

------------------------------

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


End of Opensim-dev Digest, Vol 13, Issue 14
*******************************************

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Opensim-dev Digest, Vol 13, Issue 14

Michael Emory Cerquoni
In reply to this post by steve l
I think it should be pointed out that OpenSimulator is well over 500k lines of code, its a large project, going through the code is a tedious process and because its so large its hard to connect the dots a lot of the time, so its easy to think you are improving one thing and not realizing you are breaking a dozen other things,  improvements need to be more scientific and targeted than that, testing and evaluation needs to be done in a manner that can be recreated and evaluated in a way that can definitively prove there is indeed issues.  I think the biggest thing holding OpenSimulator back at this point is our need to use the Linden Lab Second Life viewer which in many ways does things in a not so great or optimized way.  OpenSimulator tends to adapt to these issues so not to break compatibility with existing protocols.  I am not suggesting we break compatibility at this stage, there is definitely a lot of room for improvement in the back end services that OpenSimulator provides, such as Xengine and Physics and improving communication protocols.  And to address the 32bit / 64bit thing, OpenSimulator fully supports running natively in a 64 bit environment, so this is not a problem and while throwing more hardware resources at OpenSimulator is an easy and cheap thing to do now a days it is not necessarily the best solution in the long run.  I would say improvements need to be more laser focused at this point instead of trying to filter and rewrite the entire package, I think the 2 biggest lowest hanging fruits that need trimming and polishing right now are Xengine and Physics, in those order.  Another problem we have is this project is sorely lacking developers, while we do have an excellent and dedicated team of skilled developers working on things, its not enough, we need more people to get involved and contribute code and patches and help with optimization.  So if you know someone who is skilled with C# or gaming physics, more specifically Bullet, be sure to show them OpenSimulator :)  We need to also keep in mind that everyone involved is a volunteer and mostly work on things that interest them and the projects they are using OpenSimulator for, so getting everyone to shift gears is not something that will likely happen easily.

On Wed, Apr 15, 2015 at 2:03 PM, steve l <[hidden email]> wrote:
Hi!

Thank you everyone for your answers. It got me thinking again, and generally that is dangerous!

Is part of our problem in that OS was designed originally quite a few years ago and is still suffering from code that was written to satisfy the needs of the old servers we had at the time. Is Legacy code holding us back?

Is OS actually still running 32 bit code in a 64 bit world? Might that be our main bottleneck in getting frame rates up and it being able to handle the new demands we put on it?

Maybe it is time to go through OpenSim bit by bit and see what we can update and what we just don't need anymore. From what I have been hearing from many sources there are a lot of little things that are really critical issues from handling of the database to interactions and timings in Physics to networking issues and the need to update to more stout components like the internal web server.

Everyone will probably want me to blow me out of the water screaming and yelling at me, but maybe it is time to take a hard look at what needs to be done with our base system to bring it kicking and screaming into the second decade of the 21st century!

I think a lot of the time we are just patching patches. We know how well that works on car tires! Maybe it is time to put on some new tires and get rid of some of our issues once and for all!

Steve LaVigne

On Wed, Apr 15, 2015 at 7:33 AM, <[hidden email]> wrote:
Send Opensim-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opensim-dev digest..."


Today's Topics:

   1. Re: New MOSES Physics Video (UNCLASSIFIED)
      (Maxwell, Douglas CIV USARMY ARL (US))
   2. Re: Opensim-dev Digest, Vol 13, Issue 13 (steve l)


----------------------------------------------------------------------

Message: 1
Date: Wed, 15 Apr 2015 14:20:55 +0000
From: "Maxwell, Douglas CIV USARMY ARL (US)"
        <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: [Opensim-dev] New MOSES Physics Video (UNCLASSIFIED)
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Classification: UNCLASSIFIED
Caveats: NONE

1.  This is an excellent point that illustrates just how wickedly complex our problem is.  The short answer is "yes", we could do it locally.  However, the distribution of the shared experience is a hard requirement and the final state of the bricks must be accurately portrayed to all client connections.  One way to handle this is to treat this like a state machine and make sure all clients have precisely the same start conditions and then apply the same physics calculations.  Theoretically, we would have the same end conditions.  Afterward, we could queue the state changes of all the object and then have an arbitration process at the server make sure everything is actually at the same global location and orientation.

This is a complex issue as it is contrary to the current world state model and would require the server to temporarily relinquish control of prims during the physics action, then take it back after steady state.

3.  Our PhysX work is simply to ensure the physics calculations we need in the 83ms interval is actually completed and not dropped.  It is address any "rubber banding" effects you see.  It should also address jitter.  It is a balance between update rate, network saturation, and QoS.

4.  The DSG middleware approach gave us many insights into how a truly distributed simulator could work.  That was extremely valuable work for us and we were privileged to have excellent collaborators in Intel and a strong community of MOSES users willing to help us test.

v/r -douglas

Douglas Maxwell, MSME
Science and Technology Manager
Virtual World Strategic Applications
U.S. Army Research Lab
Simulation & Training Technology Center (STTC)
(c) <a href="tel:%28407%29%20242-0209" value="+14072420209" target="_blank">(407) 242-0209



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Mister Blue
Sent: Wednesday, April 15, 2015 12:21 AM
To: opensim-dev
Subject: Re: [Opensim-dev] New MOSES Physics Video

1. Is the explosion of blocks or prims something that the viewer can handle? Or is this too tricky to make happen with the wide variations of machine running viewers and even more so that soon the viewer will run in a web browser?
It is something a viewer could do but I don't know what mechanism could be used in the existing viewer.


2. Is there a way to make the explosion an overlay streaming event that runs over the current screen? - Just a crazy idea.... I am thinking of this more on a browser-viewer as that needs to run on devices that would have issues processing all that...
In interesting idea but, again, would be viewer modifications.


3. Is it possible to make OS Physics run faster than 11FPS?
Yes. The default configuration is for the simulator heartbeat time to be 11FPS and for the physics engine to be in sync. You can change the simulator heartbeat time but there are some known problems with that (too many assumptions in some places). If you run BulletSim on its own thread, you can speed up BulletSim but that would just make more updates.


4. It seems that the number of avatars exponentially changes the workload here. Maybe a graphics server could be designed as a sub service to handle that type of load, maybe running on a GPU instead of a CPU? It just seems to me that with all the other things that the region server has to do, offloading some of the heavy lifting would be a good thing. Maybe it is time to think of an OS "Pro" level of setup that separates the workload a bit more would be a good idea

That was the design of DSG. For client connections, the simulator fed on client manager who multiplied the connection to multiple viewers. So you could have a simulator feeding 10 client managers who were each feeding 30 viewers for a total of 300 connections. DSG also run script and physics servers to off load the central server from the computation from those operations.


== mb

On Tue, Apr 14, 2015 at 1:49 PM, Dahlia Trimble <[hidden email]> wrote:


        I believe there is a means in the LLUDP protocol to stuff many updates for many objects into a single packet, though I'm not sure OpenSimulator is smart enough to do it in your simulation. It may be a way to improve networking performance quite a bit when may physical objects change velocity during the same simulation frame.


        On Tue, Apr 14, 2015 at 1:44 PM, steve l <[hidden email]> wrote:


                Hi!


                Robert- Thanks for the answer and the thought you put into it!


                So I am going to play dummy (Not far from the truth!) here. This means that we need to do re-writing on several parts of OS to speed things up and eliminate bottlenecks. a couple of questions then.


                1. Is the explosion of blocks or prims something that the viewer can handle? Or is this too tricky to make happen with the wide variations of machine running viewers and even more so that soon the viewer will run in a web browser?


                2. Is there a way to make the explosion an overlay streaming event that runs over the current screen? - Just a crazy idea.... I am thinking of this more on a browser-viewer as that needs to run on devices that would have issues processing all that...


                3. Is it possible to make OS Physics run faster than 11FPS?


                4. It seems that the number of avatars exponentially changes the workload here. Maybe a graphics server could be designed as a sub service to handle that type of load, maybe running on a GPU instead of a CPU? It just seems to me that with all the other things that the region server has to do, offloading some of the heavy lifting would be a good thing. Maybe it is time to think of an OS "Pro" level of setup that separates the workload a bit more would be a good idea.


                These things always get me thinking...!


                Steve LaVigne

                A Dimension Beyond, Inc.

                www.adimensionbeyond.com


                On Tue, Apr 14, 2015 at 10:45 AM, Adams, Robert <[hidden email]> wrote:


                        I don?t think the only problem is finding a physics engine that can handle 240 moving objects. Another is optimizing the updates from the physics engine.



                        Think of the whole pipeline: the physics engine computes interactions and new locations/rotations for each object. That position update is sent to the simulator. The simulator updates the object data structures and sets an update flag. The location/position update is noticed and an update packet[1] is created and placed in output queues for each viewer. At some time, the packet is transmitted to each viewer.



                        The update processing time can easily be more than the physics engine time.



                        The OpenSimulator physics engines are run 11 times a second so they generate 11 position updates a second for each moving object. So, even an efficient physics engine will generate (240 * 11) updates per second which then turn into (240 * 11 * numberOfAvatars) packets sent per second.



                        There are many optimizations possible in this chain.



                        -- mb



                        [1] This is technically wrong for the current version of OpenSimulator. For the technically inclined, an ?update needed? packet is put in the output queue and the actual packet to transmit is created when it is time to send the update. This is done because the update output packet queue can get long and the position/location information can be stale if multiple updates are in the queue. Only one ?update needed? packet is put in the queue and the current object location/rotation is put in the transmitted packet at the time of transmission.



                        From: [hidden email] [mailto:[hidden email]] On Behalf Of steve l
                        Sent: Tuesday, April 14, 2015 8:09 AM
                        To: Michael Emory Cerquoni
                        Cc: [hidden email]; [hidden email]
                        Subject: Re: [Opensim-dev] New MOSES Physics Video



                        Hi!

                        An excellent video on the physics of exploding grenades and the wall.  On the OS Dev list Mister Blue has an excellent observation that the server crashes are due to the extreme amount of changes that have to be sent to every avatar. His idea of a client side solution might just be a good one. In the end is there any way that OpenSim can handle more events than that in it's present form? Is there any physics engine that can handle 240 moving scripted objects moving at once without lag?

                        If we could get OS to the point that it would handle this load easily, we would have all our load issues solved!

                        Steve LaVigne



                        On Tue, Apr 14, 2015 at 6:33 AM, Michael Emory Cerquoni <[hidden email]> wrote:

                        Could these test scripts be shared so testing against other engines can occur as well, I would be interested to see how this same test goes against ODE and BulletSim as well.



                        On Tue, Apr 14, 2015 at 8:18 AM, Maxwell, Douglas CIV USARMY ARL (US) <[hidden email]> wrote:

                                Good Morning, as you all know the MOSES developers are working on PhysX integration into the Open Simulator to support functionality currently not possible in the platform.  We are a methodical group and a couple months ago I asked one of our interns to work with the developers to create a series of baseline physics behavior case studies.  The first case study is a destructible wall caused by an explosive charge.  This wall is composed of blocks that are tested at a high density and a low density to simulate different destruction effects.



                                The goal here is to eventually have all of the prims in the sim loaded with the scripts needed to react to any type of random explosive charge set by the participants in the training scenario.



                                The video can be found below:



                                https://youtu.be/jSofWcwWi7g <blockedhttps://youtu.be/jSofWcwWi7g>



                                Your feedback is welcome.



                                Observations:

                                1)  Current limitations of the open simulator prevent us from expanding the tests beyond a simple wall.

                                2)  The scripts exercise the engine well and expose limitations between the sim frame rate and the physics frame rate.

                                3)  It is easy to crash the sim with this demonstration, especially if more than a handful of people are present (more than 3-4 client connections).



                                Douglas Maxwell, MSME
                                Science and Technology Manager
                                Virtual World Strategic Applications
                                U.S. Army Research Lab

                                Human Research & Engineering Directorate
                                Simulation & Training Technology Center
                                (c) <a href="tel:%28407%29%20242-0209" value="+14072420209" target="_blank">(407) 242-0209 <blockedtel:%28407%29%20242-0209>



                                _______________________________________________
                                Opensim-dev mailing list
                                [hidden email]
                                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>




                        --

                        Michael Emory Cerquoni





                _______________________________________________
                Opensim-dev mailing list
                [hidden email]
                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>





        _______________________________________________
        Opensim-dev mailing list
        [hidden email]
        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev <blockedhttp://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/20150415/878f7ce1/attachment-0001.bin>

------------------------------

Message: 2
Date: Wed, 15 Apr 2015 07:33:11 -0700
From: steve l <[hidden email]>
To: [hidden email]
Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 13, Issue 13
Message-ID:
        <CAB38sFg2m8qtfeHdFCQcuavpBq5tVDQ609MJJ67bDCiT2Mh=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Thanks Ai!

It is interesting that we were doing this apparently really well 10 years
ago! Apparently in so many ways we have to reinvent the wheel over and over!

Maybe we need to get ahold of these guys and see if they will share...

Steve LaVigne
A Dimension Beyond, Inc.
www.adimensionbeyond.com

On Wed, Apr 15, 2015 at 5:00 AM, <[hidden email]>
wrote:

> Send Opensim-dev mailing list submissions to
>         [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> or, via email, send a message with subject or body 'help' to
>         [hidden email]
>
> You can reach the person managing the list at
>         [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Opensim-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: New MOSES Physics Video (Ai Austin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Apr 2015 09:59:23 +0100
> From: Ai Austin <[hidden email]>
> To: [hidden email]
> Subject: Re: [Opensim-dev] New MOSES Physics Video
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> I saw the suggestion that explosion "physical" effects like this
> might be dealt with locally (e.g. in the same was as particle visual
> effects) in each viewer and not as a shared phenomenon where the
> position of all the parts are updated in everyone's viewer.
>
> Snow and lighting visual effects often can be approximated and
> everyone has roughly the same sort of shared experience, modulo the
> allowable and supportable  graphical quality in each viewer..
>
> I am reminded though of an exercise I took part in using the Forterra
> OLIVE when that was still being actively developed (I think it got
> sold to SAIC and I have not heard much aboit it since)...  it was a
> training exercise for military staff manning a checkpoint, and I was
> an observer through my avatar.  The military folks being trained were
> to watch fro suspicious activity, but also treat all people at the
> checkpoint well... and also to deal with the aftermath of an attack..
> rescue helicopter coming in with dust clouds from the ground and
> all... it was very realistic.  And I was very surprised, even though
> my avatar was partially protected from the checkpoint area by a solid
> wall, that an explosion injured me... the pieces flying hiring my arm
> and me being rendered unconscious!  Viewer blurring over and me being
> almost out of it.
>
> This is an example of the use of virtual worlds where the shared
> experience of what debris from an explosion goes and who it hits and
> when is necessary.  And I think may be typical of the sort of thing
> MOSES is seeking to achieve for realistic simulated
> training.  Interestingly Forterra OLIVE was itself originally
> developed on a project for the US Army also more than a decade ago.
>
> Clearly there needs to be some consideration of the granularity of
> physics and position updates across all users that are present in the
> area and a consideration of how many parts of an exploding  object
> can be made physical and updates sent and at what rate.  This could
> be a simply enormous quantity of data and updates as others have
> pointed out... so its not surprising that more avatars leads to
> slower performance.  Crashes nonetheless indicates something that is amiss.
>
>
>
> ------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
> End of Opensim-dev Digest, Vol 13, Issue 13
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/271cbab9/attachment.html>

------------------------------

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


End of Opensim-dev Digest, Vol 13, Issue 14
*******************************************


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev




--
Michael Emory Cerquoni

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Opensim-dev Digest, Vol 13, Issue 14 (UNCLASSIFIED)

Maxwell, Douglas CIV USARMY RDECOM ARL (US)
Classification: UNCLASSIFIED
Caveats: NONE

To address the request for more developers, may I offer my perspective as an
outside software development team looking at the OS:

1)  Dial down the hostility to new ideas.  Our requirements for performance
are different than your traditional use cases and we strive to look for
overlap in our efforts to benefit the community as a whole.  This is
particularly a problem on the IRC and direct IMs.  My team was harshly
criticized for simply announcing we were performing code analysis and
profiling activities.  My team has been criticized for experimenting with
PhysX implementations, although the anticipated payoff is significant.  I
think we have done an adequate job explaining why we are performing these
activities.  You can't expect to retain new developers in this atmosphere.
You'll get more developers by fostering a supportive environment.

2)  Get your documentation in shape and keep it up to date.  Telling new
developers that the code is the documentation is unacceptable.

3)  A project this size will benefit from the application of a more formal
software development management structure.  Do you guys have a schedule or
some sort of development milestones?  For people like me who want to fold into
your development processes, it would be helpful to know where you are in your
process and what is currently being worked on.  It would help me plan and
organize resources on my side.  It would also reduce redundant development
when you grow.

4)  Unless you plan to adopt the Google spiral development methodologies, you
can't stay in Beta forever.  If you would like some tips or suggestions on
long term project planning, we'd be happy to lend a hand.

5)  Backward compatibility.  You can't straddle that fence:  pick one and
don't look back.

Just my two cents.

v/r -douglas

Douglas Maxwell, MSME
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Michael Emory
Cerquoni
Sent: Wednesday, April 15, 2015 2:22 PM
To: [hidden email]
Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 13, Issue 14

I think it should be pointed out that OpenSimulator is well over 500k lines of
code, its a large project, going through the code is a tedious process and
because its so large its hard to connect the dots a lot of the time, so its
easy to think you are improving one thing and not realizing you are breaking a
dozen other things,  improvements need to be more scientific and targeted than
that, testing and evaluation needs to be done in a manner that can be
recreated and evaluated in a way that can definitively prove there is indeed
issues.  I think the biggest thing holding OpenSimulator back at this point is
our need to use the Linden Lab Second Life viewer which in many ways does
things in a not so great or optimized way.  OpenSimulator tends to adapt to
these issues so not to break compatibility with existing protocols.  I am not
suggesting we break compatibility at this stage, there is definitely a lot of
room for improvement in the back end services that OpenSimulator provides,
such as Xengine and Physics and improving communication protocols.  And to
address the 32bit / 64bit thing, OpenSimulator fully supports running natively
in a 64 bit environment, so this is not a problem and while throwing more
hardware resources at OpenSimulator is an easy and cheap thing to do now a
days it is not necessarily the best solution in the long run.  I would say
improvements need to be more laser focused at this point instead of trying to
filter and rewrite the entire package, I think the 2 biggest lowest hanging
fruits that need trimming and polishing right now are Xengine and Physics, in
those order.  Another problem we have is this project is sorely lacking
developers, while we do have an excellent and dedicated team of skilled
developers working on things, its not enough, we need more people to get
involved and contribute code and patches and help with optimization.  So if
you know someone who is skilled with C# or gaming physics, more specifically
Bullet, be sure to show them OpenSimulator :)  We need to also keep in mind
that everyone involved is a volunteer and mostly work on things that interest
them and the projects they are using OpenSimulator for, so getting everyone to
shift gears is not something that will likely happen easily.


On Wed, Apr 15, 2015 at 2:03 PM, steve l <[hidden email]> wrote:


        Hi!


        Thank you everyone for your answers. It got me thinking again, and generally
that is dangerous!


        Is part of our problem in that OS was designed originally quite a few years
ago and is still suffering from code that was written to satisfy the needs of
the old servers we had at the time. Is Legacy code holding us back?


        Is OS actually still running 32 bit code in a 64 bit world? Might that be our
main bottleneck in getting frame rates up and it being able to handle the new
demands we put on it?


        Maybe it is time to go through OpenSim bit by bit and see what we can update
and what we just don't need anymore. From what I have been hearing from many
sources there are a lot of little things that are really critical issues from
handling of the database to interactions and timings in Physics to networking
issues and the need to update to more stout components like the internal web
server.


        Everyone will probably want me to blow me out of the water screaming and
yelling at me, but maybe it is time to take a hard look at what needs to be
done with our base system to bring it kicking and screaming into the second
decade of the 21st century!


        I think a lot of the time we are just patching patches. We know how well that
works on car tires! Maybe it is time to put on some new tires and get rid of
some of our issues once and for all!


        Steve LaVigne


        On Wed, Apr 15, 2015 at 7:33 AM, <[hidden email]>
wrote:


                Send Opensim-dev mailing list submissions to
                        [hidden email]

                To subscribe or unsubscribe via the World Wide Web, visit
                        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
<blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
                or, via email, send a message with subject or body 'help' to
                        [hidden email]

                You can reach the person managing the list at
                        [hidden email]

                When replying, please edit your Subject line so it is more specific
                than "Re: Contents of Opensim-dev digest..."


                Today's Topics:

                   1. Re: New MOSES Physics Video (UNCLASSIFIED)
                      (Maxwell, Douglas CIV USARMY ARL (US))
                   2. Re: Opensim-dev Digest, Vol 13, Issue 13 (steve l)


                ----------------------------------------------------------------------

                Message: 1
                Date: Wed, 15 Apr 2015 14:20:55 +0000
                From: "Maxwell, Douglas CIV USARMY ARL (US)"
                        <[hidden email]>
                To: "[hidden email]" <[hidden email]>
                Subject: Re: [Opensim-dev] New MOSES Physics Video (UNCLASSIFIED)
                Message-ID:
                        <[hidden email]>
                Content-Type: text/plain; charset="utf-8"

                Classification: UNCLASSIFIED
                Caveats: NONE

                1.  This is an excellent point that illustrates just how wickedly complex
our problem is.  The short answer is "yes", we could do it locally.  However,
the distribution of the shared experience is a hard requirement and the final
state of the bricks must be accurately portrayed to all client connections.
One way to handle this is to treat this like a state machine and make sure all
clients have precisely the same start conditions and then apply the same
physics calculations.  Theoretically, we would have the same end conditions.
Afterward, we could queue the state changes of all the object and then have an
arbitration process at the server make sure everything is actually at the same
global location and orientation.

                This is a complex issue as it is contrary to the current world state model
and would require the server to temporarily relinquish control of prims during
the physics action, then take it back after steady state.

                3.  Our PhysX work is simply to ensure the physics calculations we need in
the 83ms interval is actually completed and not dropped.  It is address any
"rubber banding" effects you see.  It should also address jitter.  It is a
balance between update rate, network saturation, and QoS.

                4.  The DSG middleware approach gave us many insights into how a truly
distributed simulator could work.  That was extremely valuable work for us and
we were privileged to have excellent collaborators in Intel and a strong
community of MOSES users willing to help us test.

                v/r -douglas

                Douglas Maxwell, MSME
                Science and Technology Manager
                Virtual World Strategic Applications
                U.S. Army Research Lab
                Simulation & Training Technology Center (STTC)
                (c) (407) 242-0209 <blockedtel:%28407%29%20242-0209>



                -----Original Message-----
                From: [hidden email]
[mailto:[hidden email]] On Behalf Of Mister Blue
                Sent: Wednesday, April 15, 2015 12:21 AM
                To: opensim-dev
                Subject: Re: [Opensim-dev] New MOSES Physics Video

                1. Is the explosion of blocks or prims something that the viewer can handle?
Or is this too tricky to make happen with the wide variations of machine
running viewers and even more so that soon the viewer will run in a web
browser?
                It is something a viewer could do but I don't know what mechanism could be
used in the existing viewer.


                2. Is there a way to make the explosion an overlay streaming event that runs
over the current screen? - Just a crazy idea.... I am thinking of this more on
a browser-viewer as that needs to run on devices that would have issues
processing all that...
                In interesting idea but, again, would be viewer modifications.


                3. Is it possible to make OS Physics run faster than 11FPS?
                Yes. The default configuration is for the simulator heartbeat time to be
11FPS and for the physics engine to be in sync. You can change the simulator
heartbeat time but there are some known problems with that (too many
assumptions in some places). If you run BulletSim on its own thread, you can
speed up BulletSim but that would just make more updates.


                4. It seems that the number of avatars exponentially changes the workload
here. Maybe a graphics server could be designed as a sub service to handle
that type of load, maybe running on a GPU instead of a CPU? It just seems to
me that with all the other things that the region server has to do, offloading
some of the heavy lifting would be a good thing. Maybe it is time to think of
an OS "Pro" level of setup that separates the workload a bit more would be a
good idea

                That was the design of DSG. For client connections, the simulator fed on
client manager who multiplied the connection to multiple viewers. So you could
have a simulator feeding 10 client managers who were each feeding 30 viewers
for a total of 300 connections. DSG also run script and physics servers to off
load the central server from the computation from those operations.


                == mb

                On Tue, Apr 14, 2015 at 1:49 PM, Dahlia Trimble <[hidden email]>
wrote:


                        I believe there is a means in the LLUDP protocol to stuff many
updates for many objects into a single packet, though I'm not sure
OpenSimulator is smart enough to do it in your simulation. It may be a way to
improve networking performance quite a bit when may physical objects change
velocity during the same simulation frame.


                        On Tue, Apr 14, 2015 at 1:44 PM, steve l <[hidden email]>
wrote:


                                Hi!


                                Robert- Thanks for the answer and the thought you put into
it!


                                So I am going to play dummy (Not far from the truth!) here.
This means that we need to do re-writing on several parts of OS to speed
things up and eliminate bottlenecks. a couple of questions then.


                                1. Is the explosion of blocks or prims something that the
viewer can handle? Or is this too tricky to make happen with the wide
variations of machine running viewers and even more so that soon the viewer
will run in a web browser?


                                2. Is there a way to make the explosion an overlay streaming
event that runs over the current screen? - Just a crazy idea.... I am thinking
of this more on a browser-viewer as that needs to run on devices that would
have issues processing all that...


                                3. Is it possible to make OS Physics run faster than 11FPS?


                                4. It seems that the number of avatars exponentially changes
the workload here. Maybe a graphics server could be designed as a sub service
to handle that type of load, maybe running on a GPU instead of a CPU? It just
seems to me that with all the other things that the region server has to do,
offloading some of the heavy lifting would be a good thing. Maybe it is time
to think of an OS "Pro" level of setup that separates the workload a bit more
would be a good idea.


                                These things always get me thinking...!


                                Steve LaVigne

                                A Dimension Beyond, Inc.

                                www.adimensionbeyond.com


                                On Tue, Apr 14, 2015 at 10:45 AM, Adams, Robert
<[hidden email]> wrote:


                                        I don?t think the only problem is finding a physics
engine that can handle 240 moving objects. Another is optimizing the updates
from the physics engine.



                                        Think of the whole pipeline: the physics engine
computes interactions and new locations/rotations for each object. That
position update is sent to the simulator. The simulator updates the object
data structures and sets an update flag. The location/position update is
noticed and an update packet[1] is created and placed in output queues for
each viewer. At some time, the packet is transmitted to each viewer.



                                        The update processing time can easily be more than
the physics engine time.



                                        The OpenSimulator physics engines are run 11 times a
second so they generate 11 position updates a second for each moving object.
So, even an efficient physics engine will generate (240 * 11) updates per
second which then turn into (240 * 11 * numberOfAvatars) packets sent per
second.



                                        There are many optimizations possible in this chain.



                                        -- mb



                                        [1] This is technically wrong for the current
version of OpenSimulator. For the technically inclined, an ?update needed?
packet is put in the output queue and the actual packet to transmit is created
when it is time to send the update. This is done because the update output
packet queue can get long and the position/location information can be stale
if multiple updates are in the queue. Only one ?update needed? packet is put
in the queue and the current object location/rotation is put in the
transmitted packet at the time of transmission.



                                        From: [hidden email]
[mailto:[hidden email]] On Behalf Of steve l
                                        Sent: Tuesday, April 14, 2015 8:09 AM
                                        To: Michael Emory Cerquoni
                                        Cc: [hidden email];
[hidden email]
                                        Subject: Re: [Opensim-dev] New MOSES Physics Video



                                        Hi!

                                        An excellent video on the physics of exploding
grenades and the wall.  On the OS Dev list Mister Blue has an excellent
observation that the server crashes are due to the extreme amount of changes
that have to be sent to every avatar. His idea of a client side solution might
just be a good one. In the end is there any way that OpenSim can handle more
events than that in it's present form? Is there any physics engine that can
handle 240 moving scripted objects moving at once without lag?

                                        If we could get OS to the point that it would handle
this load easily, we would have all our load issues solved!

                                        Steve LaVigne



                                        On Tue, Apr 14, 2015 at 6:33 AM, Michael Emory
Cerquoni <[hidden email]> wrote:

                                        Could these test scripts be shared so testing
against other engines can occur as well, I would be interested to see how this
same test goes against ODE and BulletSim as well.



                                        On Tue, Apr 14, 2015 at 8:18 AM, Maxwell, Douglas
CIV USARMY ARL (US) <[hidden email]> wrote:

                                                Good Morning, as you all know the MOSES
developers are working on PhysX integration into the Open Simulator to support
functionality currently not possible in the platform.  We are a methodical
group and a couple months ago I asked one of our interns to work with the
developers to create a series of baseline physics behavior case studies.  The
first case study is a destructible wall caused by an explosive charge.  This
wall is composed of blocks that are tested at a high density and a low density
to simulate different destruction effects.



                                                The goal here is to eventually have all of
the prims in the sim loaded with the scripts needed to react to any type of
random explosive charge set by the participants in the training scenario.



                                                The video can be found below:



                                                https://youtu.be/jSofWcwWi7g 
<blockedhttps://youtu.be/jSofWcwWi7g>  <blockedhttps://youtu.be/jSofWcwWi7g>



                                                Your feedback is welcome.



                                                Observations:

                                                1)  Current limitations of the open
simulator prevent us from expanding the tests beyond a simple wall.

                                                2)  The scripts exercise the engine well and
expose limitations between the sim frame rate and the physics frame rate.

                                                3)  It is easy to crash the sim with this
demonstration, especially if more than a handful of people are present (more
than 3-4 client connections).



                                                Douglas Maxwell, MSME
                                                Science and Technology Manager
                                                Virtual World Strategic Applications
                                                U.S. Army Research Lab

                                                Human Research & Engineering Directorate
                                                Simulation & Training Technology Center
                                                (c) (407) 242-0209
<blockedtel:%28407%29%20242-0209>  <blockedtel:%28407%29%20242-0209>



                                                _______________________________________________
                                                Opensim-dev mailing list
                                                [hidden email]
                                                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
<blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
<blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>




                                        --

                                        Michael Emory Cerquoni





                                _______________________________________________
                                Opensim-dev mailing list
                                [hidden email]
                                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
<blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
<blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>





                        _______________________________________________
                        Opensim-dev mailing list
                        [hidden email]
                        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
<blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
<blockedhttp://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/20150415/878f7ce1/attachment-0001.bin 
<blockedhttp://opensimulator.org/pipermail/opensim-dev/attachments/20150415/878f7ce1/attachment-0001.bin>
 >

                ------------------------------

                Message: 2
                Date: Wed, 15 Apr 2015 07:33:11 -0700
                From: steve l <[hidden email]>
                To: [hidden email]
                Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 13, Issue 13
                Message-ID:
                        <CAB38sFg2m8qtfeHdFCQcuavpBq5tVDQ609MJJ67bDCiT2Mh=[hidden email]>
                Content-Type: text/plain; charset="utf-8"

                Thanks Ai!

                It is interesting that we were doing this apparently really well 10 years
                ago! Apparently in so many ways we have to reinvent the wheel over and over!

                Maybe we need to get ahold of these guys and see if they will share...

                Steve LaVigne
                A Dimension Beyond, Inc.
                www.adimensionbeyond.com

                On Wed, Apr 15, 2015 at 5:00 AM, <[hidden email]>
                wrote:

                > Send Opensim-dev mailing list submissions to
                >         [hidden email]
                >
                > To subscribe or unsubscribe via the World Wide Web, visit
                >         http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
<blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
                > or, via email, send a message with subject or body 'help' to
                >         [hidden email]
                >
                > You can reach the person managing the list at
                >         [hidden email]
                >
                > When replying, please edit your Subject line so it is more specific
                > than "Re: Contents of Opensim-dev digest..."
                >
                >
                > Today's Topics:
                >
                >    1. Re: New MOSES Physics Video (Ai Austin)
                >
                >
                > ----------------------------------------------------------------------
                >
                > Message: 1
                > Date: Wed, 15 Apr 2015 09:59:23 +0100
                > From: Ai Austin <[hidden email]>
                > To: [hidden email]
                > Subject: Re: [Opensim-dev] New MOSES Physics Video
                > Message-ID: <[hidden email]>
                > Content-Type: text/plain; charset="us-ascii"; format=flowed
                >
                > I saw the suggestion that explosion "physical" effects like this
                > might be dealt with locally (e.g. in the same was as particle visual
                > effects) in each viewer and not as a shared phenomenon where the
                > position of all the parts are updated in everyone's viewer.
                >
                > Snow and lighting visual effects often can be approximated and
                > everyone has roughly the same sort of shared experience, modulo the
                > allowable and supportable  graphical quality in each viewer..
                >
                > I am reminded though of an exercise I took part in using the Forterra
                > OLIVE when that was still being actively developed (I think it got
                > sold to SAIC and I have not heard much aboit it since)...  it was a
                > training exercise for military staff manning a checkpoint, and I was
                > an observer through my avatar.  The military folks being trained were
                > to watch fro suspicious activity, but also treat all people at the
                > checkpoint well... and also to deal with the aftermath of an attack..
                > rescue helicopter coming in with dust clouds from the ground and
                > all... it was very realistic.  And I was very surprised, even though
                > my avatar was partially protected from the checkpoint area by a solid
                > wall, that an explosion injured me... the pieces flying hiring my arm
                > and me being rendered unconscious!  Viewer blurring over and me being
                > almost out of it.
                >
                > This is an example of the use of virtual worlds where the shared
                > experience of what debris from an explosion goes and who it hits and
                > when is necessary.  And I think may be typical of the sort of thing
                > MOSES is seeking to achieve for realistic simulated
                > training.  Interestingly Forterra OLIVE was itself originally
                > developed on a project for the US Army also more than a decade ago.
                >
                > Clearly there needs to be some consideration of the granularity of
                > physics and position updates across all users that are present in the
                > area and a consideration of how many parts of an exploding  object
                > can be made physical and updates sent and at what rate.  This could
                > be a simply enormous quantity of data and updates as others have
                > pointed out... so its not surprising that more avatars leads to
                > slower performance.  Crashes nonetheless indicates something that is
amiss.
                >
                >
                >
                > ------------------------------
                >
                > _______________________________________________
                > Opensim-dev mailing list
                > [hidden email]
                > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
<blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
                >
                >
                > End of Opensim-dev Digest, Vol 13, Issue 13
                > *******************************************
                >
                -------------- next part --------------
                An HTML attachment was scrubbed...
                URL:
<http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/271cbab9/attachment.html 
<blockedhttp://opensimulator.org/pipermail/opensim-dev/attachments/20150415/271cbab9/attachment.html>
 >

                ------------------------------

                _______________________________________________
                Opensim-dev mailing list
                [hidden email]
                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
<blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>


                End of Opensim-dev Digest, Vol 13, Issue 14
                *******************************************




        _______________________________________________
        Opensim-dev mailing list
        [hidden email]
        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
<blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>






--

Michael Emory Cerquoni

Classification: UNCLASSIFIED
Caveats: NONE



_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Opensim-dev Digest, Vol 13, Issue 14 (UNCLASSIFIED)

Frank Nichols
Douglas, excellent post, i heartily agree with you points, i also understand that when there are a small number of volunteers doing all the work, those volunteers have every right to set the rules.

Btw, one small correction, the project is NOT. In beta, it is in alpha. Beta would normally imply functionality meets requirements/specifications but is not necessarily bug free. There is no requirements or specifications, so it is perpetually in alpha..

Sent from my iPad Air 2

> On Apr 16, 2015, at 8:59 AM, Maxwell, Douglas CIV USARMY ARL (US) <[hidden email]> wrote:
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> To address the request for more developers, may I offer my perspective as an
> outside software development team looking at the OS:
>
> 1)  Dial down the hostility to new ideas.  Our requirements for performance
> are different than your traditional use cases and we strive to look for
> overlap in our efforts to benefit the community as a whole.  This is
> particularly a problem on the IRC and direct IMs.  My team was harshly
> criticized for simply announcing we were performing code analysis and
> profiling activities.  My team has been criticized for experimenting with
> PhysX implementations, although the anticipated payoff is significant.  I
> think we have done an adequate job explaining why we are performing these
> activities.  You can't expect to retain new developers in this atmosphere.
> You'll get more developers by fostering a supportive environment.
>
> 2)  Get your documentation in shape and keep it up to date.  Telling new
> developers that the code is the documentation is unacceptable.
>
> 3)  A project this size will benefit from the application of a more formal
> software development management structure.  Do you guys have a schedule or
> some sort of development milestones?  For people like me who want to fold into
> your development processes, it would be helpful to know where you are in your
> process and what is currently being worked on.  It would help me plan and
> organize resources on my side.  It would also reduce redundant development
> when you grow.
>
> 4)  Unless you plan to adopt the Google spiral development methodologies, you
> can't stay in Beta forever.  If you would like some tips or suggestions on
> long term project planning, we'd be happy to lend a hand.
>
> 5)  Backward compatibility.  You can't straddle that fence:  pick one and
> don't look back.
>
> Just my two cents.
>
> v/r -douglas
>
> Douglas Maxwell, MSME
> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of Michael Emory
> Cerquoni
> Sent: Wednesday, April 15, 2015 2:22 PM
> To: [hidden email]
> Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 13, Issue 14
>
> I think it should be pointed out that OpenSimulator is well over 500k lines of
> code, its a large project, going through the code is a tedious process and
> because its so large its hard to connect the dots a lot of the time, so its
> easy to think you are improving one thing and not realizing you are breaking a
> dozen other things,  improvements need to be more scientific and targeted than
> that, testing and evaluation needs to be done in a manner that can be
> recreated and evaluated in a way that can definitively prove there is indeed
> issues.  I think the biggest thing holding OpenSimulator back at this point is
> our need to use the Linden Lab Second Life viewer which in many ways does
> things in a not so great or optimized way.  OpenSimulator tends to adapt to
> these issues so not to break compatibility with existing protocols.  I am not
> suggesting we break compatibility at this stage, there is definitely a lot of
> room for improvement in the back end services that OpenSimulator provides,
> such as Xengine and Physics and improving communication protocols.  And to
> address the 32bit / 64bit thing, OpenSimulator fully supports running natively
> in a 64 bit environment, so this is not a problem and while throwing more
> hardware resources at OpenSimulator is an easy and cheap thing to do now a
> days it is not necessarily the best solution in the long run.  I would say
> improvements need to be more laser focused at this point instead of trying to
> filter and rewrite the entire package, I think the 2 biggest lowest hanging
> fruits that need trimming and polishing right now are Xengine and Physics, in
> those order.  Another problem we have is this project is sorely lacking
> developers, while we do have an excellent and dedicated team of skilled
> developers working on things, its not enough, we need more people to get
> involved and contribute code and patches and help with optimization.  So if
> you know someone who is skilled with C# or gaming physics, more specifically
> Bullet, be sure to show them OpenSimulator :)  We need to also keep in mind
> that everyone involved is a volunteer and mostly work on things that interest
> them and the projects they are using OpenSimulator for, so getting everyone to
> shift gears is not something that will likely happen easily.
>
>
> On Wed, Apr 15, 2015 at 2:03 PM, steve l <[hidden email]> wrote:
>
>
>    Hi!
>
>
>    Thank you everyone for your answers. It got me thinking again, and generally
> that is dangerous!
>
>
>    Is part of our problem in that OS was designed originally quite a few years
> ago and is still suffering from code that was written to satisfy the needs of
> the old servers we had at the time. Is Legacy code holding us back?
>
>
>    Is OS actually still running 32 bit code in a 64 bit world? Might that be our
> main bottleneck in getting frame rates up and it being able to handle the new
> demands we put on it?
>
>
>    Maybe it is time to go through OpenSim bit by bit and see what we can update
> and what we just don't need anymore. From what I have been hearing from many
> sources there are a lot of little things that are really critical issues from
> handling of the database to interactions and timings in Physics to networking
> issues and the need to update to more stout components like the internal web
> server.
>
>
>    Everyone will probably want me to blow me out of the water screaming and
> yelling at me, but maybe it is time to take a hard look at what needs to be
> done with our base system to bring it kicking and screaming into the second
> decade of the 21st century!
>
>
>    I think a lot of the time we are just patching patches. We know how well that
> works on car tires! Maybe it is time to put on some new tires and get rid of
> some of our issues once and for all!
>
>
>    Steve LaVigne
>
>
>    On Wed, Apr 15, 2015 at 7:33 AM, <[hidden email]>
> wrote:
>
>
>        Send Opensim-dev mailing list submissions to
>                [hidden email]
>
>        To subscribe or unsubscribe via the World Wide Web, visit
>                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>        or, via email, send a message with subject or body 'help' to
>                [hidden email]
>
>        You can reach the person managing the list at
>                [hidden email]
>
>        When replying, please edit your Subject line so it is more specific
>        than "Re: Contents of Opensim-dev digest..."
>
>
>        Today's Topics:
>
>           1. Re: New MOSES Physics Video (UNCLASSIFIED)
>              (Maxwell, Douglas CIV USARMY ARL (US))
>           2. Re: Opensim-dev Digest, Vol 13, Issue 13 (steve l)
>
>
>        ----------------------------------------------------------------------
>
>        Message: 1
>        Date: Wed, 15 Apr 2015 14:20:55 +0000
>        From: "Maxwell, Douglas CIV USARMY ARL (US)"
>                <[hidden email]>
>        To: "[hidden email]" <[hidden email]>
>        Subject: Re: [Opensim-dev] New MOSES Physics Video (UNCLASSIFIED)
>        Message-ID:
>                <[hidden email]>
>        Content-Type: text/plain; charset="utf-8"
>
>        Classification: UNCLASSIFIED
>        Caveats: NONE
>
>        1.  This is an excellent point that illustrates just how wickedly complex
> our problem is.  The short answer is "yes", we could do it locally.  However,
> the distribution of the shared experience is a hard requirement and the final
> state of the bricks must be accurately portrayed to all client connections.
> One way to handle this is to treat this like a state machine and make sure all
> clients have precisely the same start conditions and then apply the same
> physics calculations.  Theoretically, we would have the same end conditions.
> Afterward, we could queue the state changes of all the object and then have an
> arbitration process at the server make sure everything is actually at the same
> global location and orientation.
>
>        This is a complex issue as it is contrary to the current world state model
> and would require the server to temporarily relinquish control of prims during
> the physics action, then take it back after steady state.
>
>        3.  Our PhysX work is simply to ensure the physics calculations we need in
> the 83ms interval is actually completed and not dropped.  It is address any
> "rubber banding" effects you see.  It should also address jitter.  It is a
> balance between update rate, network saturation, and QoS.
>
>        4.  The DSG middleware approach gave us many insights into how a truly
> distributed simulator could work.  That was extremely valuable work for us and
> we were privileged to have excellent collaborators in Intel and a strong
> community of MOSES users willing to help us test.
>
>        v/r -douglas
>
>        Douglas Maxwell, MSME
>        Science and Technology Manager
>        Virtual World Strategic Applications
>        U.S. Army Research Lab
>        Simulation & Training Technology Center (STTC)
>        (c) (407) 242-0209 <blockedtel:%28407%29%20242-0209>
>
>
>
>        -----Original Message-----
>        From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Mister Blue
>        Sent: Wednesday, April 15, 2015 12:21 AM
>        To: opensim-dev
>        Subject: Re: [Opensim-dev] New MOSES Physics Video
>
>        1. Is the explosion of blocks or prims something that the viewer can handle?
> Or is this too tricky to make happen with the wide variations of machine
> running viewers and even more so that soon the viewer will run in a web
> browser?
>        It is something a viewer could do but I don't know what mechanism could be
> used in the existing viewer.
>
>
>        2. Is there a way to make the explosion an overlay streaming event that runs
> over the current screen? - Just a crazy idea.... I am thinking of this more on
> a browser-viewer as that needs to run on devices that would have issues
> processing all that...
>        In interesting idea but, again, would be viewer modifications.
>
>
>        3. Is it possible to make OS Physics run faster than 11FPS?
>        Yes. The default configuration is for the simulator heartbeat time to be
> 11FPS and for the physics engine to be in sync. You can change the simulator
> heartbeat time but there are some known problems with that (too many
> assumptions in some places). If you run BulletSim on its own thread, you can
> speed up BulletSim but that would just make more updates.
>
>
>        4. It seems that the number of avatars exponentially changes the workload
> here. Maybe a graphics server could be designed as a sub service to handle
> that type of load, maybe running on a GPU instead of a CPU? It just seems to
> me that with all the other things that the region server has to do, offloading
> some of the heavy lifting would be a good thing. Maybe it is time to think of
> an OS "Pro" level of setup that separates the workload a bit more would be a
> good idea
>
>        That was the design of DSG. For client connections, the simulator fed on
> client manager who multiplied the connection to multiple viewers. So you could
> have a simulator feeding 10 client managers who were each feeding 30 viewers
> for a total of 300 connections. DSG also run script and physics servers to off
> load the central server from the computation from those operations.
>
>
>        == mb
>
>        On Tue, Apr 14, 2015 at 1:49 PM, Dahlia Trimble <[hidden email]>
> wrote:
>
>
>                I believe there is a means in the LLUDP protocol to stuff many
> updates for many objects into a single packet, though I'm not sure
> OpenSimulator is smart enough to do it in your simulation. It may be a way to
> improve networking performance quite a bit when may physical objects change
> velocity during the same simulation frame.
>
>
>                On Tue, Apr 14, 2015 at 1:44 PM, steve l <[hidden email]>
> wrote:
>
>
>                        Hi!
>
>
>                        Robert- Thanks for the answer and the thought you put into
> it!
>
>
>                        So I am going to play dummy (Not far from the truth!) here.
> This means that we need to do re-writing on several parts of OS to speed
> things up and eliminate bottlenecks. a couple of questions then.
>
>
>                        1. Is the explosion of blocks or prims something that the
> viewer can handle? Or is this too tricky to make happen with the wide
> variations of machine running viewers and even more so that soon the viewer
> will run in a web browser?
>
>
>                        2. Is there a way to make the explosion an overlay streaming
> event that runs over the current screen? - Just a crazy idea.... I am thinking
> of this more on a browser-viewer as that needs to run on devices that would
> have issues processing all that...
>
>
>                        3. Is it possible to make OS Physics run faster than 11FPS?
>
>
>                        4. It seems that the number of avatars exponentially changes
> the workload here. Maybe a graphics server could be designed as a sub service
> to handle that type of load, maybe running on a GPU instead of a CPU? It just
> seems to me that with all the other things that the region server has to do,
> offloading some of the heavy lifting would be a good thing. Maybe it is time
> to think of an OS "Pro" level of setup that separates the workload a bit more
> would be a good idea.
>
>
>                        These things always get me thinking...!
>
>
>                        Steve LaVigne
>
>                        A Dimension Beyond, Inc.
>
>                        www.adimensionbeyond.com
>
>
>                        On Tue, Apr 14, 2015 at 10:45 AM, Adams, Robert
> <[hidden email]> wrote:
>
>
>                                I don?t think the only problem is finding a physics
> engine that can handle 240 moving objects. Another is optimizing the updates
> from the physics engine.
>
>
>
>                                Think of the whole pipeline: the physics engine
> computes interactions and new locations/rotations for each object. That
> position update is sent to the simulator. The simulator updates the object
> data structures and sets an update flag. The location/position update is
> noticed and an update packet[1] is created and placed in output queues for
> each viewer. At some time, the packet is transmitted to each viewer.
>
>
>
>                                The update processing time can easily be more than
> the physics engine time.
>
>
>
>                                The OpenSimulator physics engines are run 11 times a
> second so they generate 11 position updates a second for each moving object.
> So, even an efficient physics engine will generate (240 * 11) updates per
> second which then turn into (240 * 11 * numberOfAvatars) packets sent per
> second.
>
>
>
>                                There are many optimizations possible in this chain.
>
>
>
>                                -- mb
>
>
>
>                                [1] This is technically wrong for the current
> version of OpenSimulator. For the technically inclined, an ?update needed?
> packet is put in the output queue and the actual packet to transmit is created
> when it is time to send the update. This is done because the update output
> packet queue can get long and the position/location information can be stale
> if multiple updates are in the queue. Only one ?update needed? packet is put
> in the queue and the current object location/rotation is put in the
> transmitted packet at the time of transmission.
>
>
>
>                                From: [hidden email]
> [mailto:[hidden email]] On Behalf Of steve l
>                                Sent: Tuesday, April 14, 2015 8:09 AM
>                                To: Michael Emory Cerquoni
>                                Cc: [hidden email];
> [hidden email]
>                                Subject: Re: [Opensim-dev] New MOSES Physics Video
>
>
>
>                                Hi!
>
>                                An excellent video on the physics of exploding
> grenades and the wall.  On the OS Dev list Mister Blue has an excellent
> observation that the server crashes are due to the extreme amount of changes
> that have to be sent to every avatar. His idea of a client side solution might
> just be a good one. In the end is there any way that OpenSim can handle more
> events than that in it's present form? Is there any physics engine that can
> handle 240 moving scripted objects moving at once without lag?
>
>                                If we could get OS to the point that it would handle
> this load easily, we would have all our load issues solved!
>
>                                Steve LaVigne
>
>
>
>                                On Tue, Apr 14, 2015 at 6:33 AM, Michael Emory
> Cerquoni <[hidden email]> wrote:
>
>                                Could these test scripts be shared so testing
> against other engines can occur as well, I would be interested to see how this
> same test goes against ODE and BulletSim as well.
>
>
>
>                                On Tue, Apr 14, 2015 at 8:18 AM, Maxwell, Douglas
> CIV USARMY ARL (US) <[hidden email]> wrote:
>
>                                        Good Morning, as you all know the MOSES
> developers are working on PhysX integration into the Open Simulator to support
> functionality currently not possible in the platform.  We are a methodical
> group and a couple months ago I asked one of our interns to work with the
> developers to create a series of baseline physics behavior case studies.  The
> first case study is a destructible wall caused by an explosive charge.  This
> wall is composed of blocks that are tested at a high density and a low density
> to simulate different destruction effects.
>
>
>
>                                        The goal here is to eventually have all of
> the prims in the sim loaded with the scripts needed to react to any type of
> random explosive charge set by the participants in the training scenario.
>
>
>
>                                        The video can be found below:
>
>
>
>                                        https://youtu.be/jSofWcwWi7g 
> <blockedhttps://youtu.be/jSofWcwWi7g>  <blockedhttps://youtu.be/jSofWcwWi7g>
>
>
>
>                                        Your feedback is welcome.
>
>
>
>                                        Observations:
>
>                                        1)  Current limitations of the open
> simulator prevent us from expanding the tests beyond a simple wall.
>
>                                        2)  The scripts exercise the engine well and
> expose limitations between the sim frame rate and the physics frame rate.
>
>                                        3)  It is easy to crash the sim with this
> demonstration, especially if more than a handful of people are present (more
> than 3-4 client connections).
>
>
>
>                                        Douglas Maxwell, MSME
>                                        Science and Technology Manager
>                                        Virtual World Strategic Applications
>                                        U.S. Army Research Lab
>
>                                        Human Research & Engineering Directorate
>                                        Simulation & Training Technology Center
>                                        (c) (407) 242-0209
> <blockedtel:%28407%29%20242-0209>  <blockedtel:%28407%29%20242-0209>
>
>
>
>                                        _______________________________________________
>                                        Opensim-dev mailing list
>                                        [hidden email]
>                                        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>
>
>
>
>                                --
>
>                                Michael Emory Cerquoni
>
>
>
>
>
>                        _______________________________________________
>                        Opensim-dev mailing list
>                        [hidden email]
>                        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>
>
>
>
>
>                _______________________________________________
>                Opensim-dev mailing list
>                [hidden email]
>                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
> <blockedhttp://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/20150415/878f7ce1/attachment-0001.bin 
> <blockedhttp://opensimulator.org/pipermail/opensim-dev/attachments/20150415/878f7ce1/attachment-0001.bin>
>>
>
>        ------------------------------
>
>        Message: 2
>        Date: Wed, 15 Apr 2015 07:33:11 -0700
>        From: steve l <[hidden email]>
>        To: [hidden email]
>        Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 13, Issue 13
>        Message-ID:
>                <CAB38sFg2m8qtfeHdFCQcuavpBq5tVDQ609MJJ67bDCiT2Mh=[hidden email]>
>        Content-Type: text/plain; charset="utf-8"
>
>        Thanks Ai!
>
>        It is interesting that we were doing this apparently really well 10 years
>        ago! Apparently in so many ways we have to reinvent the wheel over and over!
>
>        Maybe we need to get ahold of these guys and see if they will share...
>
>        Steve LaVigne
>        A Dimension Beyond, Inc.
>        www.adimensionbeyond.com
>
>        On Wed, Apr 15, 2015 at 5:00 AM, <[hidden email]>
>        wrote:
>
>        > Send Opensim-dev mailing list submissions to
>        >         [hidden email]
>        >
>        > To subscribe or unsubscribe via the World Wide Web, visit
>        >         http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>        > or, via email, send a message with subject or body 'help' to
>        >         [hidden email]
>        >
>        > You can reach the person managing the list at
>        >         [hidden email]
>        >
>        > When replying, please edit your Subject line so it is more specific
>        > than "Re: Contents of Opensim-dev digest..."
>        >
>        >
>        > Today's Topics:
>        >
>        >    1. Re: New MOSES Physics Video (Ai Austin)
>        >
>        >
>        > ----------------------------------------------------------------------
>        >
>        > Message: 1
>        > Date: Wed, 15 Apr 2015 09:59:23 +0100
>        > From: Ai Austin <[hidden email]>
>        > To: [hidden email]
>        > Subject: Re: [Opensim-dev] New MOSES Physics Video
>        > Message-ID: <[hidden email]>
>        > Content-Type: text/plain; charset="us-ascii"; format=flowed
>        >
>        > I saw the suggestion that explosion "physical" effects like this
>        > might be dealt with locally (e.g. in the same was as particle visual
>        > effects) in each viewer and not as a shared phenomenon where the
>        > position of all the parts are updated in everyone's viewer.
>        >
>        > Snow and lighting visual effects often can be approximated and
>        > everyone has roughly the same sort of shared experience, modulo the
>        > allowable and supportable  graphical quality in each viewer..
>        >
>        > I am reminded though of an exercise I took part in using the Forterra
>        > OLIVE when that was still being actively developed (I think it got
>        > sold to SAIC and I have not heard much aboit it since)...  it was a
>        > training exercise for military staff manning a checkpoint, and I was
>        > an observer through my avatar.  The military folks being trained were
>        > to watch fro suspicious activity, but also treat all people at the
>        > checkpoint well... and also to deal with the aftermath of an attack..
>        > rescue helicopter coming in with dust clouds from the ground and
>        > all... it was very realistic.  And I was very surprised, even though
>        > my avatar was partially protected from the checkpoint area by a solid
>        > wall, that an explosion injured me... the pieces flying hiring my arm
>        > and me being rendered unconscious!  Viewer blurring over and me being
>        > almost out of it.
>        >
>        > This is an example of the use of virtual worlds where the shared
>        > experience of what debris from an explosion goes and who it hits and
>        > when is necessary.  And I think may be typical of the sort of thing
>        > MOSES is seeking to achieve for realistic simulated
>        > training.  Interestingly Forterra OLIVE was itself originally
>        > developed on a project for the US Army also more than a decade ago.
>        >
>        > Clearly there needs to be some consideration of the granularity of
>        > physics and position updates across all users that are present in the
>        > area and a consideration of how many parts of an exploding  object
>        > can be made physical and updates sent and at what rate.  This could
>        > be a simply enormous quantity of data and updates as others have
>        > pointed out... so its not surprising that more avatars leads to
>        > slower performance.  Crashes nonetheless indicates something that is
> amiss.
>        >
>        >
>        >
>        > ------------------------------
>        >
>        > _______________________________________________
>        > Opensim-dev mailing list
>        > [hidden email]
>        > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>        >
>        >
>        > End of Opensim-dev Digest, Vol 13, Issue 13
>        > *******************************************
>        >
>        -------------- next part --------------
>        An HTML attachment was scrubbed...
>        URL:
> <http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/271cbab9/attachment.html 
> <blockedhttp://opensimulator.org/pipermail/opensim-dev/attachments/20150415/271cbab9/attachment.html>
>>
>
>        ------------------------------
>
>        _______________________________________________
>        Opensim-dev mailing list
>        [hidden email]
>        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>
>
>        End of Opensim-dev Digest, Vol 13, Issue 14
>        *******************************************
>
>
>
>
>    _______________________________________________
>    Opensim-dev mailing list
>    [hidden email]
>    http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev 
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>
>
>
>
>
>
> --
>
> Michael Emory Cerquoni
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Opensim-dev Digest, Vol 13, Issue 14 (UNCLASSIFIED)

Paola Cerioli
I am very grateful with what everything has been done with Opensim. I wish that I could help, and although I have written software professionally all my life, I have never used C#, so my help is a bit limited. What I am working on is building code around it (so pretty much building services that connect directly to the database, bypassing Robust). 

If the Opensim development team is just for C#, I totally understand. But if you ever decide to take some parts of the code out and use different technologies/languages, maybe there are more developers willing to help. 

We could even use Docker and create small incapsulated code talking with each other, each of them to be built with the best tool for the job. With microservices, we could really do a lot and engage more people in the project.

What I am trying to say is that you have done an *amazing* job, and I am extremely grateful. But like me, there are many developers out there doing their own isolated implementation of code related to Opensim. If there was a way to join forces, it will probably help the longevity of the code.

My 2 cents :)






On Thu, Apr 16, 2015 at 8:00 AM, Frank Nichols <[hidden email]> wrote:
Douglas, excellent post, i heartily agree with you points, i also understand that when there are a small number of volunteers doing all the work, those volunteers have every right to set the rules.

Btw, one small correction, the project is NOT. In beta, it is in alpha. Beta would normally imply functionality meets requirements/specifications but is not necessarily bug free. There is no requirements or specifications, so it is perpetually in alpha..

Sent from my iPad Air 2

> On Apr 16, 2015, at 8:59 AM, Maxwell, Douglas CIV USARMY ARL (US) <[hidden email]> wrote:
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> To address the request for more developers, may I offer my perspective as an
> outside software development team looking at the OS:
>
> 1)  Dial down the hostility to new ideas.  Our requirements for performance
> are different than your traditional use cases and we strive to look for
> overlap in our efforts to benefit the community as a whole.  This is
> particularly a problem on the IRC and direct IMs.  My team was harshly
> criticized for simply announcing we were performing code analysis and
> profiling activities.  My team has been criticized for experimenting with
> PhysX implementations, although the anticipated payoff is significant.  I
> think we have done an adequate job explaining why we are performing these
> activities.  You can't expect to retain new developers in this atmosphere.
> You'll get more developers by fostering a supportive environment.
>
> 2)  Get your documentation in shape and keep it up to date.  Telling new
> developers that the code is the documentation is unacceptable.
>
> 3)  A project this size will benefit from the application of a more formal
> software development management structure.  Do you guys have a schedule or
> some sort of development milestones?  For people like me who want to fold into
> your development processes, it would be helpful to know where you are in your
> process and what is currently being worked on.  It would help me plan and
> organize resources on my side.  It would also reduce redundant development
> when you grow.
>
> 4)  Unless you plan to adopt the Google spiral development methodologies, you
> can't stay in Beta forever.  If you would like some tips or suggestions on
> long term project planning, we'd be happy to lend a hand.
>
> 5)  Backward compatibility.  You can't straddle that fence:  pick one and
> don't look back.
>
> Just my two cents.
>
> v/r -douglas
>
> Douglas Maxwell, MSME
> Science and Technology Manager
> Virtual World Strategic Applications
> U.S. Army Research Lab
> Simulation & Training Technology Center (STTC)
> (c) <a href="tel:%28407%29%20242-0209" value="+14072420209">(407) 242-0209
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Michael Emory
> Cerquoni
> Sent: Wednesday, April 15, 2015 2:22 PM
> To: [hidden email]
> Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 13, Issue 14
>
> I think it should be pointed out that OpenSimulator is well over 500k lines of
> code, its a large project, going through the code is a tedious process and
> because its so large its hard to connect the dots a lot of the time, so its
> easy to think you are improving one thing and not realizing you are breaking a
> dozen other things,  improvements need to be more scientific and targeted than
> that, testing and evaluation needs to be done in a manner that can be
> recreated and evaluated in a way that can definitively prove there is indeed
> issues.  I think the biggest thing holding OpenSimulator back at this point is
> our need to use the Linden Lab Second Life viewer which in many ways does
> things in a not so great or optimized way.  OpenSimulator tends to adapt to
> these issues so not to break compatibility with existing protocols.  I am not
> suggesting we break compatibility at this stage, there is definitely a lot of
> room for improvement in the back end services that OpenSimulator provides,
> such as Xengine and Physics and improving communication protocols.  And to
> address the 32bit / 64bit thing, OpenSimulator fully supports running natively
> in a 64 bit environment, so this is not a problem and while throwing more
> hardware resources at OpenSimulator is an easy and cheap thing to do now a
> days it is not necessarily the best solution in the long run.  I would say
> improvements need to be more laser focused at this point instead of trying to
> filter and rewrite the entire package, I think the 2 biggest lowest hanging
> fruits that need trimming and polishing right now are Xengine and Physics, in
> those order.  Another problem we have is this project is sorely lacking
> developers, while we do have an excellent and dedicated team of skilled
> developers working on things, its not enough, we need more people to get
> involved and contribute code and patches and help with optimization.  So if
> you know someone who is skilled with C# or gaming physics, more specifically
> Bullet, be sure to show them OpenSimulator :)  We need to also keep in mind
> that everyone involved is a volunteer and mostly work on things that interest
> them and the projects they are using OpenSimulator for, so getting everyone to
> shift gears is not something that will likely happen easily.
>
>
> On Wed, Apr 15, 2015 at 2:03 PM, steve l <[hidden email]> wrote:
>
>
>    Hi!
>
>
>    Thank you everyone for your answers. It got me thinking again, and generally
> that is dangerous!
>
>
>    Is part of our problem in that OS was designed originally quite a few years
> ago and is still suffering from code that was written to satisfy the needs of
> the old servers we had at the time. Is Legacy code holding us back?
>
>
>    Is OS actually still running 32 bit code in a 64 bit world? Might that be our
> main bottleneck in getting frame rates up and it being able to handle the new
> demands we put on it?
>
>
>    Maybe it is time to go through OpenSim bit by bit and see what we can update
> and what we just don't need anymore. From what I have been hearing from many
> sources there are a lot of little things that are really critical issues from
> handling of the database to interactions and timings in Physics to networking
> issues and the need to update to more stout components like the internal web
> server.
>
>
>    Everyone will probably want me to blow me out of the water screaming and
> yelling at me, but maybe it is time to take a hard look at what needs to be
> done with our base system to bring it kicking and screaming into the second
> decade of the 21st century!
>
>
>    I think a lot of the time we are just patching patches. We know how well that
> works on car tires! Maybe it is time to put on some new tires and get rid of
> some of our issues once and for all!
>
>
>    Steve LaVigne
>
>
>    On Wed, Apr 15, 2015 at 7:33 AM, <[hidden email]>
> wrote:
>
>
>        Send Opensim-dev mailing list submissions to
>                [hidden email]
>
>        To subscribe or unsubscribe via the World Wide Web, visit
>                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>        or, via email, send a message with subject or body 'help' to
>                [hidden email]
>
>        You can reach the person managing the list at
>                [hidden email]
>
>        When replying, please edit your Subject line so it is more specific
>        than "Re: Contents of Opensim-dev digest..."
>
>
>        Today's Topics:
>
>           1. Re: New MOSES Physics Video (UNCLASSIFIED)
>              (Maxwell, Douglas CIV USARMY ARL (US))
>           2. Re: Opensim-dev Digest, Vol 13, Issue 13 (steve l)
>
>
>        ----------------------------------------------------------------------
>
>        Message: 1
>        Date: Wed, 15 Apr 2015 14:20:55 +0000
>        From: "Maxwell, Douglas CIV USARMY ARL (US)"
>                <[hidden email]>
>        To: "[hidden email]" <[hidden email]>
>        Subject: Re: [Opensim-dev] New MOSES Physics Video (UNCLASSIFIED)
>        Message-ID:
>                <[hidden email]>
>        Content-Type: text/plain; charset="utf-8"
>
>        Classification: UNCLASSIFIED
>        Caveats: NONE
>
>        1.  This is an excellent point that illustrates just how wickedly complex
> our problem is.  The short answer is "yes", we could do it locally.  However,
> the distribution of the shared experience is a hard requirement and the final
> state of the bricks must be accurately portrayed to all client connections.
> One way to handle this is to treat this like a state machine and make sure all
> clients have precisely the same start conditions and then apply the same
> physics calculations.  Theoretically, we would have the same end conditions.
> Afterward, we could queue the state changes of all the object and then have an
> arbitration process at the server make sure everything is actually at the same
> global location and orientation.
>
>        This is a complex issue as it is contrary to the current world state model
> and would require the server to temporarily relinquish control of prims during
> the physics action, then take it back after steady state.
>
>        3.  Our PhysX work is simply to ensure the physics calculations we need in
> the 83ms interval is actually completed and not dropped.  It is address any
> "rubber banding" effects you see.  It should also address jitter.  It is a
> balance between update rate, network saturation, and QoS.
>
>        4.  The DSG middleware approach gave us many insights into how a truly
> distributed simulator could work.  That was extremely valuable work for us and
> we were privileged to have excellent collaborators in Intel and a strong
> community of MOSES users willing to help us test.
>
>        v/r -douglas
>
>        Douglas Maxwell, MSME
>        Science and Technology Manager
>        Virtual World Strategic Applications
>        U.S. Army Research Lab
>        Simulation & Training Technology Center (STTC)
>        (c) <a href="tel:%28407%29%20242-0209" value="+14072420209">(407) 242-0209 <blockedtel:%28407%29%20242-0209>
>
>
>
>        -----Original Message-----
>        From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Mister Blue
>        Sent: Wednesday, April 15, 2015 12:21 AM
>        To: opensim-dev
>        Subject: Re: [Opensim-dev] New MOSES Physics Video
>
>        1. Is the explosion of blocks or prims something that the viewer can handle?
> Or is this too tricky to make happen with the wide variations of machine
> running viewers and even more so that soon the viewer will run in a web
> browser?
>        It is something a viewer could do but I don't know what mechanism could be
> used in the existing viewer.
>
>
>        2. Is there a way to make the explosion an overlay streaming event that runs
> over the current screen? - Just a crazy idea.... I am thinking of this more on
> a browser-viewer as that needs to run on devices that would have issues
> processing all that...
>        In interesting idea but, again, would be viewer modifications.
>
>
>        3. Is it possible to make OS Physics run faster than 11FPS?
>        Yes. The default configuration is for the simulator heartbeat time to be
> 11FPS and for the physics engine to be in sync. You can change the simulator
> heartbeat time but there are some known problems with that (too many
> assumptions in some places). If you run BulletSim on its own thread, you can
> speed up BulletSim but that would just make more updates.
>
>
>        4. It seems that the number of avatars exponentially changes the workload
> here. Maybe a graphics server could be designed as a sub service to handle
> that type of load, maybe running on a GPU instead of a CPU? It just seems to
> me that with all the other things that the region server has to do, offloading
> some of the heavy lifting would be a good thing. Maybe it is time to think of
> an OS "Pro" level of setup that separates the workload a bit more would be a
> good idea
>
>        That was the design of DSG. For client connections, the simulator fed on
> client manager who multiplied the connection to multiple viewers. So you could
> have a simulator feeding 10 client managers who were each feeding 30 viewers
> for a total of 300 connections. DSG also run script and physics servers to off
> load the central server from the computation from those operations.
>
>
>        == mb
>
>        On Tue, Apr 14, 2015 at 1:49 PM, Dahlia Trimble <[hidden email]>
> wrote:
>
>
>                I believe there is a means in the LLUDP protocol to stuff many
> updates for many objects into a single packet, though I'm not sure
> OpenSimulator is smart enough to do it in your simulation. It may be a way to
> improve networking performance quite a bit when may physical objects change
> velocity during the same simulation frame.
>
>
>                On Tue, Apr 14, 2015 at 1:44 PM, steve l <[hidden email]>
> wrote:
>
>
>                        Hi!
>
>
>                        Robert- Thanks for the answer and the thought you put into
> it!
>
>
>                        So I am going to play dummy (Not far from the truth!) here.
> This means that we need to do re-writing on several parts of OS to speed
> things up and eliminate bottlenecks. a couple of questions then.
>
>
>                        1. Is the explosion of blocks or prims something that the
> viewer can handle? Or is this too tricky to make happen with the wide
> variations of machine running viewers and even more so that soon the viewer
> will run in a web browser?
>
>
>                        2. Is there a way to make the explosion an overlay streaming
> event that runs over the current screen? - Just a crazy idea.... I am thinking
> of this more on a browser-viewer as that needs to run on devices that would
> have issues processing all that...
>
>
>                        3. Is it possible to make OS Physics run faster than 11FPS?
>
>
>                        4. It seems that the number of avatars exponentially changes
> the workload here. Maybe a graphics server could be designed as a sub service
> to handle that type of load, maybe running on a GPU instead of a CPU? It just
> seems to me that with all the other things that the region server has to do,
> offloading some of the heavy lifting would be a good thing. Maybe it is time
> to think of an OS "Pro" level of setup that separates the workload a bit more
> would be a good idea.
>
>
>                        These things always get me thinking...!
>
>
>                        Steve LaVigne
>
>                        A Dimension Beyond, Inc.
>
>                        www.adimensionbeyond.com
>
>
>                        On Tue, Apr 14, 2015 at 10:45 AM, Adams, Robert
> <[hidden email]> wrote:
>
>
>                                I don?t think the only problem is finding a physics
> engine that can handle 240 moving objects. Another is optimizing the updates
> from the physics engine.
>
>
>
>                                Think of the whole pipeline: the physics engine
> computes interactions and new locations/rotations for each object. That
> position update is sent to the simulator. The simulator updates the object
> data structures and sets an update flag. The location/position update is
> noticed and an update packet[1] is created and placed in output queues for
> each viewer. At some time, the packet is transmitted to each viewer.
>
>
>
>                                The update processing time can easily be more than
> the physics engine time.
>
>
>
>                                The OpenSimulator physics engines are run 11 times a
> second so they generate 11 position updates a second for each moving object.
> So, even an efficient physics engine will generate (240 * 11) updates per
> second which then turn into (240 * 11 * numberOfAvatars) packets sent per
> second.
>
>
>
>                                There are many optimizations possible in this chain.
>
>
>
>                                -- mb
>
>
>
>                                [1] This is technically wrong for the current
> version of OpenSimulator. For the technically inclined, an ?update needed?
> packet is put in the output queue and the actual packet to transmit is created
> when it is time to send the update. This is done because the update output
> packet queue can get long and the position/location information can be stale
> if multiple updates are in the queue. Only one ?update needed? packet is put
> in the queue and the current object location/rotation is put in the
> transmitted packet at the time of transmission.
>
>
>
>                                From: [hidden email]
> [mailto:[hidden email]] On Behalf Of steve l
>                                Sent: Tuesday, April 14, 2015 8:09 AM
>                                To: Michael Emory Cerquoni
>                                Cc: [hidden email];
> [hidden email]
>                                Subject: Re: [Opensim-dev] New MOSES Physics Video
>
>
>
>                                Hi!
>
>                                An excellent video on the physics of exploding
> grenades and the wall.  On the OS Dev list Mister Blue has an excellent
> observation that the server crashes are due to the extreme amount of changes
> that have to be sent to every avatar. His idea of a client side solution might
> just be a good one. In the end is there any way that OpenSim can handle more
> events than that in it's present form? Is there any physics engine that can
> handle 240 moving scripted objects moving at once without lag?
>
>                                If we could get OS to the point that it would handle
> this load easily, we would have all our load issues solved!
>
>                                Steve LaVigne
>
>
>
>                                On Tue, Apr 14, 2015 at 6:33 AM, Michael Emory
> Cerquoni <[hidden email]> wrote:
>
>                                Could these test scripts be shared so testing
> against other engines can occur as well, I would be interested to see how this
> same test goes against ODE and BulletSim as well.
>
>
>
>                                On Tue, Apr 14, 2015 at 8:18 AM, Maxwell, Douglas
> CIV USARMY ARL (US) <[hidden email]> wrote:
>
>                                        Good Morning, as you all know the MOSES
> developers are working on PhysX integration into the Open Simulator to support
> functionality currently not possible in the platform.  We are a methodical
> group and a couple months ago I asked one of our interns to work with the
> developers to create a series of baseline physics behavior case studies.  The
> first case study is a destructible wall caused by an explosive charge.  This
> wall is composed of blocks that are tested at a high density and a low density
> to simulate different destruction effects.
>
>
>
>                                        The goal here is to eventually have all of
> the prims in the sim loaded with the scripts needed to react to any type of
> random explosive charge set by the participants in the training scenario.
>
>
>
>                                        The video can be found below:
>
>
>
>                                        https://youtu.be/jSofWcwWi7g
> <blockedhttps://youtu.be/jSofWcwWi7g>  <blockedhttps://youtu.be/jSofWcwWi7g>
>
>
>
>                                        Your feedback is welcome.
>
>
>
>                                        Observations:
>
>                                        1)  Current limitations of the open
> simulator prevent us from expanding the tests beyond a simple wall.
>
>                                        2)  The scripts exercise the engine well and
> expose limitations between the sim frame rate and the physics frame rate.
>
>                                        3)  It is easy to crash the sim with this
> demonstration, especially if more than a handful of people are present (more
> than 3-4 client connections).
>
>
>
>                                        Douglas Maxwell, MSME
>                                        Science and Technology Manager
>                                        Virtual World Strategic Applications
>                                        U.S. Army Research Lab
>
>                                        Human Research & Engineering Directorate
>                                        Simulation & Training Technology Center
>                                        (c) <a href="tel:%28407%29%20242-0209" value="+14072420209">(407) 242-0209
> <blockedtel:%28407%29%20242-0209>  <blockedtel:%28407%29%20242-0209>
>
>
>
>                                        _______________________________________________
>                                        Opensim-dev mailing list
>                                        [hidden email]
>                                        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>
>
>
>
>                                --
>
>                                Michael Emory Cerquoni
>
>
>
>
>
>                        _______________________________________________
>                        Opensim-dev mailing list
>                        [hidden email]
>                        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>
>
>
>
>
>                _______________________________________________
>                Opensim-dev mailing list
>                [hidden email]
>                http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
> <blockedhttp://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/20150415/878f7ce1/attachment-0001.bin
> <blockedhttp://opensimulator.org/pipermail/opensim-dev/attachments/20150415/878f7ce1/attachment-0001.bin>
>>
>
>        ------------------------------
>
>        Message: 2
>        Date: Wed, 15 Apr 2015 07:33:11 -0700
>        From: steve l <[hidden email]>
>        To: [hidden email]
>        Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 13, Issue 13
>        Message-ID:
>                <CAB38sFg2m8qtfeHdFCQcuavpBq5tVDQ609MJJ67bDCiT2Mh=[hidden email]>
>        Content-Type: text/plain; charset="utf-8"
>
>        Thanks Ai!
>
>        It is interesting that we were doing this apparently really well 10 years
>        ago! Apparently in so many ways we have to reinvent the wheel over and over!
>
>        Maybe we need to get ahold of these guys and see if they will share...
>
>        Steve LaVigne
>        A Dimension Beyond, Inc.
>        www.adimensionbeyond.com
>
>        On Wed, Apr 15, 2015 at 5:00 AM, <[hidden email]>
>        wrote:
>
>        > Send Opensim-dev mailing list submissions to
>        >         [hidden email]
>        >
>        > To subscribe or unsubscribe via the World Wide Web, visit
>        >         http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>        > or, via email, send a message with subject or body 'help' to
>        >         [hidden email]
>        >
>        > You can reach the person managing the list at
>        >         [hidden email]
>        >
>        > When replying, please edit your Subject line so it is more specific
>        > than "Re: Contents of Opensim-dev digest..."
>        >
>        >
>        > Today's Topics:
>        >
>        >    1. Re: New MOSES Physics Video (Ai Austin)
>        >
>        >
>        > ----------------------------------------------------------------------
>        >
>        > Message: 1
>        > Date: Wed, 15 Apr 2015 09:59:23 +0100
>        > From: Ai Austin <[hidden email]>
>        > To: [hidden email]
>        > Subject: Re: [Opensim-dev] New MOSES Physics Video
>        > Message-ID: <[hidden email]>
>        > Content-Type: text/plain; charset="us-ascii"; format=flowed
>        >
>        > I saw the suggestion that explosion "physical" effects like this
>        > might be dealt with locally (e.g. in the same was as particle visual
>        > effects) in each viewer and not as a shared phenomenon where the
>        > position of all the parts are updated in everyone's viewer.
>        >
>        > Snow and lighting visual effects often can be approximated and
>        > everyone has roughly the same sort of shared experience, modulo the
>        > allowable and supportable  graphical quality in each viewer..
>        >
>        > I am reminded though of an exercise I took part in using the Forterra
>        > OLIVE when that was still being actively developed (I think it got
>        > sold to SAIC and I have not heard much aboit it since)...  it was a
>        > training exercise for military staff manning a checkpoint, and I was
>        > an observer through my avatar.  The military folks being trained were
>        > to watch fro suspicious activity, but also treat all people at the
>        > checkpoint well... and also to deal with the aftermath of an attack..
>        > rescue helicopter coming in with dust clouds from the ground and
>        > all... it was very realistic.  And I was very surprised, even though
>        > my avatar was partially protected from the checkpoint area by a solid
>        > wall, that an explosion injured me... the pieces flying hiring my arm
>        > and me being rendered unconscious!  Viewer blurring over and me being
>        > almost out of it.
>        >
>        > This is an example of the use of virtual worlds where the shared
>        > experience of what debris from an explosion goes and who it hits and
>        > when is necessary.  And I think may be typical of the sort of thing
>        > MOSES is seeking to achieve for realistic simulated
>        > training.  Interestingly Forterra OLIVE was itself originally
>        > developed on a project for the US Army also more than a decade ago.
>        >
>        > Clearly there needs to be some consideration of the granularity of
>        > physics and position updates across all users that are present in the
>        > area and a consideration of how many parts of an exploding  object
>        > can be made physical and updates sent and at what rate.  This could
>        > be a simply enormous quantity of data and updates as others have
>        > pointed out... so its not surprising that more avatars leads to
>        > slower performance.  Crashes nonetheless indicates something that is
> amiss.
>        >
>        >
>        >
>        > ------------------------------
>        >
>        > _______________________________________________
>        > Opensim-dev mailing list
>        > [hidden email]
>        > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>        >
>        >
>        > End of Opensim-dev Digest, Vol 13, Issue 13
>        > *******************************************
>        >
>        -------------- next part --------------
>        An HTML attachment was scrubbed...
>        URL:
> <http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/271cbab9/attachment.html
> <blockedhttp://opensimulator.org/pipermail/opensim-dev/attachments/20150415/271cbab9/attachment.html>
>>
>
>        ------------------------------
>
>        _______________________________________________
>        Opensim-dev mailing list
>        [hidden email]
>        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>
>
>        End of Opensim-dev Digest, Vol 13, Issue 14
>        *******************************************
>
>
>
>
>    _______________________________________________
>    Opensim-dev mailing list
>    [hidden email]
>    http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> <blockedhttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
>
>
>
>
>
>
> --
>
> Michael Emory Cerquoni
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev



--
~~~~~~~~~~~~~~~~~~~~~~
Paola Cerioli
[hidden email]
http://www.eDreamFactory.com

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Opensim-dev Digest, Vol 13, Issue 14 (UNCLASSIFIED)

M.E. Verhagen
In reply to this post by Maxwell, Douglas CIV USARMY RDECOM ARL (US)


1)  Dial down the hostility to new ideas. 
      
       Yes I agree, new ideas should be welcome. Sad to hear you get the feeling otherwise.
      

2)  Get your documentation in shape and keep it up to date.  Telling new
developers that the code is the documentation is unacceptable.

       I haven't got a real opnion on the docs.  

3)  A project this size will benefit from the application of a more formal
software development management structure. 

      The schedule is to reverse enginere untill the ties with SL are broken I gues ?
      I would love to see a good opensim viewer just doing the opensim things right. That would be a good basis for a sound developer structure for the server side.      
 
4)   you..can't stay in Beta forever.

      Opensim has not got a beta, alpha or other status. That would actualy suggest there is some sort of roadmap present, but there is none. 
 
5)  Backward compatibility.  You can't straddle that fence:  pick one and
don't look back.

      Any change wich breaks compatabilty is bad. 
      I see backwards compatabilty as a form of respect for the people using opensim.


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Opensim-dev Digest, Vol 13, Issue 14

Shaun T. Erickson
In reply to this post by Frank Nichols
I asked if there was a way to donate to the developers and Nebadon told
me they don't take donations, or I might have.

On 4/15/15 2:19 PM, Frank Nichols wrote:
> And just to be fair, do you financially support any/all of the
> developers? I do.
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Opensim-dev Digest, Vol 13, Issue 14

Frank Nichols
Strange, justin had a system in place a while back and i setup a recurring payment. I have not checked to see if it is still being made, i will look into it.

Sent from my iPad Air 2

> On Apr 25, 2015, at 11:02 PM, Shaun T. Erickson <[hidden email]> wrote:
>
> I asked if there was a way to donate to the developers and Nebadon told me they don't take donations, or I might have.
>
>> On 4/15/15 2:19 PM, Frank Nichols wrote:
>> And just to be fair, do you financially support any/all of the developers? I do.
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|

Re: Opensim-dev Digest, Vol 13, Issue 14

Kevin Cozens
> On Apr 25, 2015, at 11:02 PM, Shaun T. Erickson <[hidden email]> wrote:
>
> I asked if there was a way to donate to the developers and Nebadon told
> me they don't take donations, or I might have.

It can depend on the developer and the project(s) they work on. I don't
know about those that work on OS but in general some developers working
on a project take donations via PayPal. Some developers have wish lists
on websites like Amazon where you can buy items for them off their list.
Typically this is more for projects being developed by a single
individual than for a larger group effort such as that of the OpenSim
project.

--

Cheers!

Kevin.

http://www.ve3syb.ca/           |"Nerds make the shiny things that
distract
Owner of Elecraft K2 #2172      | the mouth-breathers, and that's why
we're
                                 | powerful!"
#include <disclaimer/favourite> |             --Chris Hardwick

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev