<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div>Hi again!<br><br></div>Michael & Frank- I agree with you both on most everything.<br><br></div>I do think we need to give up our associations with Second Life. Linden Labs has gone beyond the current version of SL and we should do the same. If they don't care why should we?<br><br></div>In a reasonably short amount of time all the alternative viewers that now run SL will no longer do that as SL will be something else entirely soon and none of the old stuff will work or matter.<br><br></div><div>As Michael says, one of the biggest issues is the viewer. If we took a hard look at the viewer, and made it as good and efficient as possible ripping out the unnecessary old SL legacy parts, I think that would be a giant step in bringing OS into the future. I also think we need to look hard at what are the best and worst parts of our viewers and make something that is all OS, incredibly efficient and secure, and works everywhere easily with no learning curve.<br><br></div><div>The Other thing Michael Brings up are Xengine and Physics. Yes we need to really focus our time on these as these are what the heart of OpenSim really is and a lot of what holds it back right now for people wanting a higher level of reality in demonstrations and learning. MOSES is working really hard on quantifying exactly what is going on in the black box that is the server. Hopefully their tools and Sean working with new physics engines might help that along quite a bit. <br></div><div><br></div>OpenSim is an incredible thing with a rich history that could fade to obscurity if we don't look at our future carefully. Virtual Reality and Virtual worlds are taking off like a rocket now and a whole lot more people and investors are getting interested. There are many alternatives out there like High Fidelity, Unity and others that are trying to reinvent the wheel. SL and OpenSim are the old guys now and OS is still in it's alpha stages after all this time. The key point here is that unlike the others we have something that really works quite well in many ways. We are way ahead because of that.<br><br></div>What worries me the most is that OpenSim will get left in the dust and become irrelevant being run over by all the bright new guys out there. There are some really good things going on like the work that Michael, Christa, Justin, MOSES, and a pile of really smart people are doing. <br><br></div>What are we going to do when this VR thing really takes off and EVERYBODY wants a piece of it? OS has proved itself to be really good for many things in education and business. The people involved in it are very passionate about their baby, as they should be.<br><br></div>I am not a coder or an engineer. I am really more of a user and visionary. I have been around OpenSim for about 8 of those 10 years. I have seen it grow and improve dramatically over that time. OpenSim has become in many ways a joy to work with. We can thank our hard working Developers for that. I just want to make sure it stays relevant in the future. We need to keep our lead.<br><br></div>I think that we as people passionate about OpenSim should get together and work together to get OpenSim to where it needs to be on an Enterprise level. In many ways it is very close to there.<br><br></div>We also need to get investors excited about what we are doing and interested in putting some of their money into our endeavors. They are investing in the other guys, why not us too? Money always seems to be the issue- Lets sell ourselves some and actually get it all done and make a living from it in the process! You can't work for free forever!<br><br></div>Getting the right people interested and investing will take us to where we need to be a whole lot sooner and assure our future.<br><br></div>Steve L<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 15, 2015 at 11:21 AM, <span dir="ltr"><<a href="mailto:opensim-dev-request@opensimulator.org" target="_blank">opensim-dev-request@opensimulator.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Opensim-dev mailing list submissions to<br>
<a href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:opensim-dev-request@opensimulator.org">opensim-dev-request@opensimulator.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:opensim-dev-owner@opensimulator.org">opensim-dev-owner@opensimulator.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Opensim-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Opensim-dev Digest, Vol 13, Issue 14 (Michael Emory Cerquoni)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 15 Apr 2015 14:21:38 -0400<br>
From: Michael Emory Cerquoni <<a href="mailto:nebadon2025@gmail.com">nebadon2025@gmail.com</a>><br>
To: <a href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a><br>
Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 13, Issue 14<br>
Message-ID:<br>
<CAF5=<a href="mailto:rqXGD747nnNaeQF_q0zaR3MfvT5fPqv7uB8-uEeKEu4n0Q@mail.gmail.com">rqXGD747nnNaeQF_q0zaR3MfvT5fPqv7uB8-uEeKEu4n0Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I think it should be pointed out that OpenSimulator is well over 500k lines<br>
of code, its a large project, going through the code is a tedious process<br>
and because its so large its hard to connect the dots a lot of the time, so<br>
its easy to think you are improving one thing and not realizing you are<br>
breaking a dozen other things, improvements need to be more scientific and<br>
targeted than that, testing and evaluation needs to be done in a manner<br>
that can be recreated and evaluated in a way that can definitively prove<br>
there is indeed issues. I think the biggest thing holding OpenSimulator<br>
back at this point is our need to use the Linden Lab Second Life viewer<br>
which in many ways does things in a not so great or optimized way.<br>
OpenSimulator tends to adapt to these issues so not to break compatibility<br>
with existing protocols. I am not suggesting we break compatibility at<br>
this stage, there is definitely a lot of room for improvement in the back<br>
end services that OpenSimulator provides, such as Xengine and Physics and<br>
improving communication protocols. And to address the 32bit / 64bit thing,<br>
OpenSimulator fully supports running natively in a 64 bit environment, so<br>
this is not a problem and while throwing more hardware resources at<br>
OpenSimulator is an easy and cheap thing to do now a days it is not<br>
necessarily the best solution in the long run. I would say improvements<br>
need to be more laser focused at this point instead of trying to filter and<br>
rewrite the entire package, I think the 2 biggest lowest hanging fruits<br>
that need trimming and polishing right now are Xengine and Physics, in<br>
those order. Another problem we have is this project is sorely lacking<br>
developers, while we do have an excellent and dedicated team of skilled<br>
developers working on things, its not enough, we need more people to get<br>
involved and contribute code and patches and help with optimization. So if<br>
you know someone who is skilled with C# or gaming physics, more<br>
specifically Bullet, be sure to show them OpenSimulator :) We need to also<br>
keep in mind that everyone involved is a volunteer and mostly work on<br>
things that interest them and the projects they are using OpenSimulator<br>
for, so getting everyone to shift gears is not something that will likely<br>
happen easily.<br>
<br>
On Wed, Apr 15, 2015 at 2:03 PM, steve l <<a href="mailto:salbiedermann@gmail.com">salbiedermann@gmail.com</a>> wrote:<br>
<br>
> Hi!<br>
><br>
> Thank you everyone for your answers. It got me thinking again, and<br>
> generally that is dangerous!<br>
><br>
> Is part of our problem in that OS was designed originally quite a few<br>
> years ago and is still suffering from code that was written to satisfy the<br>
> needs of the old servers we had at the time. Is Legacy code holding us back?<br>
><br>
> Is OS actually still running 32 bit code in a 64 bit world? Might that be<br>
> our main bottleneck in getting frame rates up and it being able to handle<br>
> the new demands we put on it?<br>
><br>
> Maybe it is time to go through OpenSim bit by bit and see what we can<br>
> update and what we just don't need anymore. From what I have been hearing<br>
> from many sources there are a lot of little things that are really critical<br>
> issues from handling of the database to interactions and timings in Physics<br>
> to networking issues and the need to update to more stout components like<br>
> the internal web server.<br>
><br>
> Everyone will probably want me to blow me out of the water screaming and<br>
> yelling at me, but maybe it is time to take a hard look at what needs to be<br>
> done with our base system to bring it kicking and screaming into the second<br>
> decade of the 21st century!<br>
><br>
> I think a lot of the time we are just patching patches. We know how well<br>
> that works on car tires! Maybe it is time to put on some new tires and get<br>
> rid of some of our issues once and for all!<br>
><br>
> Steve LaVigne<br>
><br>
> On Wed, Apr 15, 2015 at 7:33 AM, <<a href="mailto:opensim-dev-request@opensimulator.org">opensim-dev-request@opensimulator.org</a>><br>
> wrote:<br>
><br>
>> Send Opensim-dev mailing list submissions to<br>
>> <a href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a><br>
>><br>
>> To subscribe or unsubscribe via the World Wide Web, visit<br>
>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>> or, via email, send a message with subject or body 'help' to<br>
>> <a href="mailto:opensim-dev-request@opensimulator.org">opensim-dev-request@opensimulator.org</a><br>
>><br>
>> You can reach the person managing the list at<br>
>> <a href="mailto:opensim-dev-owner@opensimulator.org">opensim-dev-owner@opensimulator.org</a><br>
>><br>
>> When replying, please edit your Subject line so it is more specific<br>
>> than "Re: Contents of Opensim-dev digest..."<br>
>><br>
>><br>
>> Today's Topics:<br>
>><br>
>> 1. Re: New MOSES Physics Video (UNCLASSIFIED)<br>
>> (Maxwell, Douglas CIV USARMY ARL (US))<br>
>> 2. Re: Opensim-dev Digest, Vol 13, Issue 13 (steve l)<br>
>><br>
>><br>
>> ----------------------------------------------------------------------<br>
>><br>
>> Message: 1<br>
>> Date: Wed, 15 Apr 2015 14:20:55 +0000<br>
>> From: "Maxwell, Douglas CIV USARMY ARL (US)"<br>
>> <<a href="mailto:douglas.maxwell3.civ@mail.mil">douglas.maxwell3.civ@mail.mil</a>><br>
>> To: "<a href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a>" <<a href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a>><br>
>> Subject: Re: [Opensim-dev] New MOSES Physics Video (UNCLASSIFIED)<br>
>> Message-ID:<br>
>> <<br>
>> <a href="mailto:180878FAC40F8447ADED7BA2DE0775FD33CA19E4@ugunhpso.easf.csd.disa.mil">180878FAC40F8447ADED7BA2DE0775FD33CA19E4@ugunhpso.easf.csd.disa.mil</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Classification: UNCLASSIFIED<br>
>> Caveats: NONE<br>
>><br>
>> 1. This is an excellent point that illustrates just how wickedly complex<br>
>> our problem is. The short answer is "yes", we could do it locally.<br>
>> However, the distribution of the shared experience is a hard requirement<br>
>> and the final state of the bricks must be accurately portrayed to all<br>
>> client connections. One way to handle this is to treat this like a state<br>
>> machine and make sure all clients have precisely the same start conditions<br>
>> and then apply the same physics calculations. Theoretically, we would have<br>
>> the same end conditions. Afterward, we could queue the state changes of<br>
>> all the object and then have an arbitration process at the server make sure<br>
>> everything is actually at the same global location and orientation.<br>
>><br>
>> This is a complex issue as it is contrary to the current world state<br>
>> model and would require the server to temporarily relinquish control of<br>
>> prims during the physics action, then take it back after steady state.<br>
>><br>
>> 3. Our PhysX work is simply to ensure the physics calculations we need<br>
>> in the 83ms interval is actually completed and not dropped. It is address<br>
>> any "rubber banding" effects you see. It should also address jitter. It<br>
>> is a balance between update rate, network saturation, and QoS.<br>
>><br>
>> 4. The DSG middleware approach gave us many insights into how a truly<br>
>> distributed simulator could work. That was extremely valuable work for us<br>
>> and we were privileged to have excellent collaborators in Intel and a<br>
>> strong community of MOSES users willing to help us test.<br>
>><br>
>> v/r -douglas<br>
>><br>
>> Douglas Maxwell, MSME<br>
>> Science and Technology Manager<br>
>> Virtual World Strategic Applications<br>
>> U.S. Army Research Lab<br>
>> Simulation & Training Technology Center (STTC)<br>
>> (c) <a href="tel:%28407%29%20242-0209" value="+14072420209">(407) 242-0209</a><br>
>><br>
>><br>
>><br>
>> -----Original Message-----<br>
>> From: <a href="mailto:opensim-dev-bounces@opensimulator.org">opensim-dev-bounces@opensimulator.org</a> [mailto:<br>
>> <a href="mailto:opensim-dev-bounces@opensimulator.org">opensim-dev-bounces@opensimulator.org</a>] On Behalf Of Mister Blue<br>
>> Sent: Wednesday, April 15, 2015 12:21 AM<br>
>> To: opensim-dev<br>
>> Subject: Re: [Opensim-dev] New MOSES Physics Video<br>
>><br>
>> 1. Is the explosion of blocks or prims something that the viewer can<br>
>> handle? Or is this too tricky to make happen with the wide variations of<br>
>> machine running viewers and even more so that soon the viewer will run in a<br>
>> web browser?<br>
>> It is something a viewer could do but I don't know what mechanism could<br>
>> be used in the existing viewer.<br>
>><br>
>><br>
>> 2. Is there a way to make the explosion an overlay streaming event that<br>
>> runs over the current screen? - Just a crazy idea.... I am thinking of this<br>
>> more on a browser-viewer as that needs to run on devices that would have<br>
>> issues processing all that...<br>
>> In interesting idea but, again, would be viewer modifications.<br>
>><br>
>><br>
>> 3. Is it possible to make OS Physics run faster than 11FPS?<br>
>> Yes. The default configuration is for the simulator heartbeat time to be<br>
>> 11FPS and for the physics engine to be in sync. You can change the<br>
>> simulator heartbeat time but there are some known problems with that (too<br>
>> many assumptions in some places). If you run BulletSim on its own thread,<br>
>> you can speed up BulletSim but that would just make more updates.<br>
>><br>
>><br>
>> 4. It seems that the number of avatars exponentially changes the workload<br>
>> here. Maybe a graphics server could be designed as a sub service to handle<br>
>> that type of load, maybe running on a GPU instead of a CPU? It just seems<br>
>> to me that with all the other things that the region server has to do,<br>
>> offloading some of the heavy lifting would be a good thing. Maybe it is<br>
>> time to think of an OS "Pro" level of setup that separates the workload a<br>
>> bit more would be a good idea<br>
>><br>
>> That was the design of DSG. For client connections, the simulator fed on<br>
>> client manager who multiplied the connection to multiple viewers. So you<br>
>> could have a simulator feeding 10 client managers who were each feeding 30<br>
>> viewers for a total of 300 connections. DSG also run script and physics<br>
>> servers to off load the central server from the computation from those<br>
>> operations.<br>
>><br>
>><br>
>> == mb<br>
>><br>
>> On Tue, Apr 14, 2015 at 1:49 PM, Dahlia Trimble <<a href="mailto:dahliatrimble@gmail.com">dahliatrimble@gmail.com</a>><br>
>> wrote:<br>
>><br>
>><br>
>> I believe there is a means in the LLUDP protocol to stuff many<br>
>> updates for many objects into a single packet, though I'm not sure<br>
>> OpenSimulator is smart enough to do it in your simulation. It may be a way<br>
>> to improve networking performance quite a bit when may physical objects<br>
>> change velocity during the same simulation frame.<br>
>><br>
>><br>
>> On Tue, Apr 14, 2015 at 1:44 PM, steve l <<a href="mailto:salbiedermann@gmail.com">salbiedermann@gmail.com</a>><br>
>> wrote:<br>
>><br>
>><br>
>> Hi!<br>
>><br>
>><br>
>> Robert- Thanks for the answer and the thought you put<br>
>> into it!<br>
>><br>
>><br>
>> So I am going to play dummy (Not far from the truth!)<br>
>> here. This means that we need to do re-writing on several parts of OS to<br>
>> speed things up and eliminate bottlenecks. a couple of questions then.<br>
>><br>
>><br>
>> 1. Is the explosion of blocks or prims something that the<br>
>> viewer can handle? Or is this too tricky to make happen with the wide<br>
>> variations of machine running viewers and even more so that soon the viewer<br>
>> will run in a web browser?<br>
>><br>
>><br>
>> 2. Is there a way to make the explosion an overlay<br>
>> streaming event that runs over the current screen? - Just a crazy idea....<br>
>> I am thinking of this more on a browser-viewer as that needs to run on<br>
>> devices that would have issues processing all that...<br>
>><br>
>><br>
>> 3. Is it possible to make OS Physics run faster than<br>
>> 11FPS?<br>
>><br>
>><br>
>> 4. It seems that the number of avatars exponentially<br>
>> changes the workload here. Maybe a graphics server could be designed as a<br>
>> sub service to handle that type of load, maybe running on a GPU instead of<br>
>> a CPU? It just seems to me that with all the other things that the region<br>
>> server has to do, offloading some of the heavy lifting would be a good<br>
>> thing. Maybe it is time to think of an OS "Pro" level of setup that<br>
>> separates the workload a bit more would be a good idea.<br>
>><br>
>><br>
>> These things always get me thinking...!<br>
>><br>
>><br>
>> Steve LaVigne<br>
>><br>
>> A Dimension Beyond, Inc.<br>
>><br>
>> <a href="http://www.adimensionbeyond.com" target="_blank">www.adimensionbeyond.com</a><br>
>><br>
>><br>
>> On Tue, Apr 14, 2015 at 10:45 AM, Adams, Robert <<br>
>> <a href="mailto:robert.adams@intel.com">robert.adams@intel.com</a>> wrote:<br>
>><br>
>><br>
>> I don?t think the only problem is finding a<br>
>> physics engine that can handle 240 moving objects. Another is optimizing<br>
>> the updates from the physics engine.<br>
>><br>
>><br>
>><br>
>> Think of the whole pipeline: the physics engine<br>
>> computes interactions and new locations/rotations for each object. That<br>
>> position update is sent to the simulator. The simulator updates the object<br>
>> data structures and sets an update flag. The location/position update is<br>
>> noticed and an update packet[1] is created and placed in output queues for<br>
>> each viewer. At some time, the packet is transmitted to each viewer.<br>
>><br>
>><br>
>><br>
>> The update processing time can easily be more<br>
>> than the physics engine time.<br>
>><br>
>><br>
>><br>
>> The OpenSimulator physics engines are run 11<br>
>> times a second so they generate 11 position updates a second for each<br>
>> moving object. So, even an efficient physics engine will generate (240 *<br>
>> 11) updates per second which then turn into (240 * 11 * numberOfAvatars)<br>
>> packets sent per second.<br>
>><br>
>><br>
>><br>
>> There are many optimizations possible in this<br>
>> chain.<br>
>><br>
>><br>
>><br>
>> -- mb<br>
>><br>
>><br>
>><br>
>> [1] This is technically wrong for the current<br>
>> version of OpenSimulator. For the technically inclined, an ?update needed?<br>
>> packet is put in the output queue and the actual packet to transmit is<br>
>> created when it is time to send the update. This is done because the update<br>
>> output packet queue can get long and the position/location information can<br>
>> be stale if multiple updates are in the queue. Only one ?update needed?<br>
>> packet is put in the queue and the current object location/rotation is put<br>
>> in the transmitted packet at the time of transmission.<br>
>><br>
>><br>
>><br>
>> From: <a href="mailto:owner-moses-list@lists.mitre.org">owner-moses-list@lists.mitre.org</a> [mailto:<br>
>> <a href="mailto:owner-moses-list@lists.mitre.org">owner-moses-list@lists.mitre.org</a>] On Behalf Of steve l<br>
>> Sent: Tuesday, April 14, 2015 8:09 AM<br>
>> To: Michael Emory Cerquoni<br>
>> Cc: <a href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a>;<br>
>> <a href="mailto:moses-list@lists.mitre.org">moses-list@lists.mitre.org</a><br>
>> Subject: Re: [Opensim-dev] New MOSES Physics Video<br>
>><br>
>><br>
>><br>
>> Hi!<br>
>><br>
>> An excellent video on the physics of exploding<br>
>> grenades and the wall. On the OS Dev list Mister Blue has an excellent<br>
>> observation that the server crashes are due to the extreme amount of<br>
>> changes that have to be sent to every avatar. His idea of a client side<br>
>> solution might just be a good one. In the end is there any way that OpenSim<br>
>> can handle more events than that in it's present form? Is there any physics<br>
>> engine that can handle 240 moving scripted objects moving at once without<br>
>> lag?<br>
>><br>
>> If we could get OS to the point that it would<br>
>> handle this load easily, we would have all our load issues solved!<br>
>><br>
>> Steve LaVigne<br>
>><br>
>><br>
>><br>
>> On Tue, Apr 14, 2015 at 6:33 AM, Michael Emory<br>
>> Cerquoni <<a href="mailto:nebadon2025@gmail.com">nebadon2025@gmail.com</a>> wrote:<br>
>><br>
>> Could these test scripts be shared so testing<br>
>> against other engines can occur as well, I would be interested to see how<br>
>> this same test goes against ODE and BulletSim as well.<br>
>><br>
>><br>
>><br>
>> On Tue, Apr 14, 2015 at 8:18 AM, Maxwell, Douglas<br>
>> CIV USARMY ARL (US) <<a href="mailto:douglas.maxwell3.civ@mail.mil">douglas.maxwell3.civ@mail.mil</a>> wrote:<br>
>><br>
>> Good Morning, as you all know the MOSES<br>
>> developers are working on PhysX integration into the Open Simulator to<br>
>> support functionality currently not possible in the platform. We are a<br>
>> methodical group and a couple months ago I asked one of our interns to work<br>
>> with the developers to create a series of baseline physics behavior case<br>
>> studies. The first case study is a destructible wall caused by an<br>
>> explosive charge. This wall is composed of blocks that are tested at a<br>
>> high density and a low density to simulate different destruction effects.<br>
>><br>
>><br>
>><br>
>> The goal here is to eventually have all<br>
>> of the prims in the sim loaded with the scripts needed to react to any type<br>
>> of random explosive charge set by the participants in the training scenario.<br>
>><br>
>><br>
>><br>
>> The video can be found below:<br>
>><br>
>><br>
>><br>
>> <a href="https://youtu.be/jSofWcwWi7g" target="_blank">https://youtu.be/jSofWcwWi7g</a><br>
>> <blockedhttps://<a href="http://youtu.be/jSofWcwWi7g" target="_blank">youtu.be/jSofWcwWi7g</a>><br>
>><br>
>><br>
>><br>
>> Your feedback is welcome.<br>
>><br>
>><br>
>><br>
>> Observations:<br>
>><br>
>> 1) Current limitations of the open<br>
>> simulator prevent us from expanding the tests beyond a simple wall.<br>
>><br>
>> 2) The scripts exercise the engine well<br>
>> and expose limitations between the sim frame rate and the physics frame<br>
>> rate.<br>
>><br>
>> 3) It is easy to crash the sim with this<br>
>> demonstration, especially if more than a handful of people are present<br>
>> (more than 3-4 client connections).<br>
>><br>
>><br>
>><br>
>> Douglas Maxwell, MSME<br>
>> Science and Technology Manager<br>
>> Virtual World Strategic Applications<br>
>> U.S. Army Research Lab<br>
>><br>
>> Human Research & Engineering Directorate<br>
>> Simulation & Training Technology Center<br>
>> (c) <a href="tel:%28407%29%20242-0209" value="+14072420209">(407) 242-0209</a><br>
>> <blockedtel:%28407%29%20242-0209><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>><br>
>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>> <blockedhttp://<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>> Michael Emory Cerquoni<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>><br>
>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>> <blockedhttp://<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>> <blockedhttp://<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Classification: UNCLASSIFIED<br>
>> Caveats: NONE<br>
>><br>
>><br>
>> -------------- next part --------------<br>
>> A non-text attachment was scrubbed...<br>
>> Name: smime.p7s<br>
>> Type: application/x-pkcs7-signature<br>
>> Size: 5629 bytes<br>
>> Desc: not available<br>
>> URL: <<br>
>> <a href="http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/878f7ce1/attachment-0001.bin" target="_blank">http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/878f7ce1/attachment-0001.bin</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 2<br>
>> Date: Wed, 15 Apr 2015 07:33:11 -0700<br>
>> From: steve l <<a href="mailto:salbiedermann@gmail.com">salbiedermann@gmail.com</a>><br>
>> To: <a href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a><br>
>> Subject: Re: [Opensim-dev] Opensim-dev Digest, Vol 13, Issue 13<br>
>> Message-ID:<br>
>> <CAB38sFg2m8qtfeHdFCQcuavpBq5tVDQ609MJJ67bDCiT2Mh=<br>
>> <a href="mailto:dw@mail.gmail.com">dw@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Thanks Ai!<br>
>><br>
>> It is interesting that we were doing this apparently really well 10 years<br>
>> ago! Apparently in so many ways we have to reinvent the wheel over and<br>
>> over!<br>
>><br>
>> Maybe we need to get ahold of these guys and see if they will share...<br>
>><br>
>> Steve LaVigne<br>
>> A Dimension Beyond, Inc.<br>
>> <a href="http://www.adimensionbeyond.com" target="_blank">www.adimensionbeyond.com</a><br>
>><br>
>> On Wed, Apr 15, 2015 at 5:00 AM, <<a href="mailto:opensim-dev-request@opensimulator.org">opensim-dev-request@opensimulator.org</a>><br>
>> wrote:<br>
>><br>
>> > Send Opensim-dev mailing list submissions to<br>
>> > <a href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a><br>
>> ><br>
>> > To subscribe or unsubscribe via the World Wide Web, visit<br>
>> > <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>> > or, via email, send a message with subject or body 'help' to<br>
>> > <a href="mailto:opensim-dev-request@opensimulator.org">opensim-dev-request@opensimulator.org</a><br>
>> ><br>
>> > You can reach the person managing the list at<br>
>> > <a href="mailto:opensim-dev-owner@opensimulator.org">opensim-dev-owner@opensimulator.org</a><br>
>> ><br>
>> > When replying, please edit your Subject line so it is more specific<br>
>> > than "Re: Contents of Opensim-dev digest..."<br>
>> ><br>
>> ><br>
>> > Today's Topics:<br>
>> ><br>
>> > 1. Re: New MOSES Physics Video (Ai Austin)<br>
>> ><br>
>> ><br>
>> > ----------------------------------------------------------------------<br>
>> ><br>
>> > Message: 1<br>
>> > Date: Wed, 15 Apr 2015 09:59:23 +0100<br>
>> > From: Ai Austin <<a href="mailto:ai.ai.austin@gmail.com">ai.ai.austin@gmail.com</a>><br>
>> > To: <a href="mailto:opensim-dev@opensimulator.org">opensim-dev@opensimulator.org</a><br>
>> > Subject: Re: [Opensim-dev] New MOSES Physics Video<br>
>> > Message-ID: <<a href="mailto:552e28de.ad3ec20a.7807.ffffc879@mx.google.com">552e28de.ad3ec20a.7807.ffffc879@mx.google.com</a>><br>
>> > Content-Type: text/plain; charset="us-ascii"; format=flowed<br>
>> ><br>
>> > I saw the suggestion that explosion "physical" effects like this<br>
>> > might be dealt with locally (e.g. in the same was as particle visual<br>
>> > effects) in each viewer and not as a shared phenomenon where the<br>
>> > position of all the parts are updated in everyone's viewer.<br>
>> ><br>
>> > Snow and lighting visual effects often can be approximated and<br>
>> > everyone has roughly the same sort of shared experience, modulo the<br>
>> > allowable and supportable graphical quality in each viewer..<br>
>> ><br>
>> > I am reminded though of an exercise I took part in using the Forterra<br>
>> > OLIVE when that was still being actively developed (I think it got<br>
>> > sold to SAIC and I have not heard much aboit it since)... it was a<br>
>> > training exercise for military staff manning a checkpoint, and I was<br>
>> > an observer through my avatar. The military folks being trained were<br>
>> > to watch fro suspicious activity, but also treat all people at the<br>
>> > checkpoint well... and also to deal with the aftermath of an attack..<br>
>> > rescue helicopter coming in with dust clouds from the ground and<br>
>> > all... it was very realistic. And I was very surprised, even though<br>
>> > my avatar was partially protected from the checkpoint area by a solid<br>
>> > wall, that an explosion injured me... the pieces flying hiring my arm<br>
>> > and me being rendered unconscious! Viewer blurring over and me being<br>
>> > almost out of it.<br>
>> ><br>
>> > This is an example of the use of virtual worlds where the shared<br>
>> > experience of what debris from an explosion goes and who it hits and<br>
>> > when is necessary. And I think may be typical of the sort of thing<br>
>> > MOSES is seeking to achieve for realistic simulated<br>
>> > training. Interestingly Forterra OLIVE was itself originally<br>
>> > developed on a project for the US Army also more than a decade ago.<br>
>> ><br>
>> > Clearly there needs to be some consideration of the granularity of<br>
>> > physics and position updates across all users that are present in the<br>
>> > area and a consideration of how many parts of an exploding object<br>
>> > can be made physical and updates sent and at what rate. This could<br>
>> > be a simply enormous quantity of data and updates as others have<br>
>> > pointed out... so its not surprising that more avatars leads to<br>
>> > slower performance. Crashes nonetheless indicates something that is<br>
>> amiss.<br>
>> ><br>
>> ><br>
>> ><br>
>> > ------------------------------<br>
>> ><br>
>> > _______________________________________________<br>
>> > Opensim-dev mailing list<br>
>> > <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> > <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>> ><br>
>> ><br>
>> > End of Opensim-dev Digest, Vol 13, Issue 13<br>
>> > *******************************************<br>
>> ><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/271cbab9/attachment.html" target="_blank">http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/271cbab9/attachment.html</a><br>
>> ><br>
>><br>
>> ------------------------------<br>
>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>><br>
>><br>
>> End of Opensim-dev Digest, Vol 13, Issue 14<br>
>> *******************************************<br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
<br>
<br>
--<br>
Michael Emory Cerquoni<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/8ca3484a/attachment.html" target="_blank">http://opensimulator.org/pipermail/opensim-dev/attachments/20150415/8ca3484a/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br>
<br>
End of Opensim-dev Digest, Vol 13, Issue 17<br>
*******************************************<br>
</blockquote></div><br></div>