Re: [Opensim-dev] PhysicalPrimMax numbers for BulletSim

[Justin Clark-Casey]

Very nice.  And various helpful bug reports I see - ra is going to be busy :)

On 08/11/12 20:41, Teravus Ovares wrote:

Not sure if you saw, however this is some good stuff.
http://opensimulator.org/mantis/view.php?id=6409
:)
Regards
Teravus

On Wed, Nov 7, 2012 at 4:35 PM, Adams, Robert mailto:robert.ad...@intel.com>> wrote:

There has been an ongoing discussion on physical prim maximum size. Lani 
Global did some testing and published a
graph of her results at 
http://opensimulator.org/wiki/User:LaniGlobal#PhysicalPrimMax_Size_Testing . 
Her testing
showed that, for ODE, a max size of 32m resulted in a livable frame rate 
degradation.

__ __

I performed the same tests with BulletSim and discovered that a single 
sphere (native physical shape) or a single
torus (mesh/hull shape) did not reduce simulator frame rate no matter the 
size of the object.

__ __

So, I created a single, standalone region with lumpy terrain and dropped 
different quantities of large shapes. The
resulting frame rates were:

__ __

  NumberNumber

SPHERE1   4   8  16  32TORUS[2] 1   4   8  32  64

+ +

 10 | 55  55  55  55  55   10 | 55  55  55  55  55

S  20 | 55  55  55  55  55 S 20 | 55  55  55  26  13

i  32 | 55  55  55  55  55 i 32 | 55  55  40  16

z  64 | 55  55  55  49  49 z 64 | 55  50  20

e  100| 55  54  49  47  [1]e 100| 40  15

__ __

   [1] My setup wasn’t large enough to hold 32 100m spheres.

   [2] The torus height is about one third of the width because I preferred 
the doughnut shape.

__ __

A few pictures of the experiments (one region with walls):

https://dl.dropbox.com/u/86260377/20121107_009.png 

https://dl.dropbox.com/u/86260377/20121107_012.png 

https://dl.dropbox.com/u/86260377/20121107_017.png 

https://dl.dropbox.com/u/86260377/20121107_019.png 

https://dl.dropbox.com/u/86260377/20121107_022.png 

https://dl.dropbox.com/u/86260377/20121107_026.png 

__ __

It looks like, for BulletSim, a physical object max size of 32m is 
acceptable and 64m would probably be OK. 

The physics frame rate is a function of the number and size of large, 
physical prims.  The above numbers are for
multiple of the same object. The next tests should be on large sized 
linksets (for instance, two 5m cubes that are
32m apart and linked and physical).

__ __

-- ra

__ __


___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de 
https://lists.berlios.de/mailman/listinfo/opensim-dev




___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev




--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] BulletSim testing

[Teravus Ovares]

BulletSim Thousand Cube stack test.
http://www.youtube.com/watch?v=JpYKI_vfZkI


Regards

Teravus

On Thu, Nov 8, 2012 at 7:39 AM, R.Gunther  wrote:

> Why blog, this mailinglist works much better.
>
>
> On 2012-11-08 05:32, OpenSimFan wrote:
>
>> maybe create a blog to explain things, and for users to share idea's...
>>
>>
>>
>> -
>> __**___
>> Keep up the good work.!!! - OpenSimFan
>> My Opensim/Second Life Blog
>> http://verwijs.wordpress.com
>> (Dutch, basic hardware/software help  windows, Mac, Linux)
>> http://verwijs-pc.nl
>> My Twitter Page:
>> http://twitter.com/OpenSimFan
>> My Facebook page (be my friend, please )
>> http://www.facebook.com/andre.**verwijs
>> --
>> View this message in context: http://opensim-dev.2196679.n2.**
>> nabble.com/BulletSim-testing-**tp7578304p7578308.html
>> Sent from the opensim-dev mailing list archive at Nabble.com.
>> __**_
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>>
>>
> __**_
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] BulletSim testing

[drWhiet]

Some great videos for this can be found here :
http://opensimulator.org/mantis/view.php?id=6409
( BulletSim Tori Chain / double anchor point chain / BulletSim Tori Chain
Scaled up to 115 physical links) 

View this message in context:
http://opensim-dev.2196679.n2.nabble.com/BulletSim-testing-tp7578304p7578308
.html

best regards,
Wordfromthe Wise (exited)

-Ursprüngliche Nachricht-
Von: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von R.Gunther
Gesendet: Donnerstag, 8. November 2012 14:39
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] BulletSim testing

Why blog, this mailinglist works much better.

On 2012-11-08 05:32, OpenSimFan wrote:
> maybe create a blog to explain things, and for users to share idea's...
>
>
>
> -
> _
> Keep up the good work.!!! - OpenSimFan My Opensim/Second Life Blog 
> http://verwijs.wordpress.com (Dutch, basic hardware/software help  
> windows, Mac, Linux) http://verwijs-pc.nl My Twitter Page:
> http://twitter.com/OpenSimFan
> My Facebook page (be my friend, please ) 
> http://www.facebook.com/andre.verwijs
> --
> View this message in context: 
> http://opensim-dev.2196679.n2.nabble.com/BulletSim-testing-tp7578304p7
> 578308.html Sent from the opensim-dev mailing list archive at 
> Nabble.com.
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] PhysicalPrimMax numbers for BulletSim

[Teravus Ovares]

Not sure if you saw, however this is some good stuff.

http://opensimulator.org/mantis/view.php?id=6409

:)

Regards

Teravus

On Wed, Nov 7, 2012 at 4:35 PM, Adams, Robert wrote:

>  There has been an ongoing discussion on physical prim maximum size. Lani
> Global did some testing and published a graph of her results at
> http://opensimulator.org/wiki/User:LaniGlobal#PhysicalPrimMax_Size_Testing. 
> Her testing showed that, for ODE, a max size of 32m resulted in a livable
> frame rate degradation.
>
> ** **
>
> I performed the same tests with BulletSim and discovered that a single
> sphere (native physical shape) or a single torus (mesh/hull shape) did not
> reduce simulator frame rate no matter the size of the object.
>
> ** **
>
> So, I created a single, standalone region with lumpy terrain and dropped
> different quantities of large shapes. The resulting frame rates were:
>
> ** **
>
>  NumberNumber
>
> SPHERE1   4   8  16  32TORUS[2] 1   4   8  32  64
>
>+ +
>
> 10 | 55  55  55  55  55   10 | 55  55  55  55  55
>
> S  20 | 55  55  55  55  55 S 20 | 55  55  55  26  13
>
> i  32 | 55  55  55  55  55 i 32 | 55  55  40  16
>
> z  64 | 55  55  55  49  49 z 64 | 55  50  20
>
> e  100| 55  54  49  47  [1]e 100| 40  15
>
> ** **
>
>   [1] My setup wasn’t large enough to hold 32 100m spheres.
>
>   [2] The torus height is about one third of the width because I preferred
> the doughnut shape.
>
> ** **
>
> A few pictures of the experiments (one region with walls):
>
> https://dl.dropbox.com/u/86260377/20121107_009.png 
>
> https://dl.dropbox.com/u/86260377/20121107_012.png 
>
> https://dl.dropbox.com/u/86260377/20121107_017.png 
>
> https://dl.dropbox.com/u/86260377/20121107_019.png 
>
> https://dl.dropbox.com/u/86260377/20121107_022.png 
>
> https://dl.dropbox.com/u/86260377/20121107_026.png 
>
> ** **
>
> It looks like, for BulletSim, a physical object max size of 32m is
> acceptable and 64m would probably be OK. 
>
> The physics frame rate is a function of the number and size of large,
> physical prims.  The above numbers are for multiple of the same object. The
> next tests should be on large sized linksets (for instance, two 5m cubes
> that are 32m apart and linked and physical).
>
> ** **
>
> -- ra
>
> ** **
>
> ___
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] Update for group module & flotsam

[Michelle Argus]

NP Justin.

I tested the new MessageOnlineUsersOnly and it is a big improvment 
eventhough some lag still was noticable. The lag is noticable from the 
moment the IM is beeing sent from the viewer untill all IMs were sent to 
the online group members. With the new option we have 3 lag creating steps:

- Query the groupmembers from the group server ( time is not logged)
- Query the presence server for online members (time is not logged)
- Sending the IMs (ranged between 59 - 3200 ms for constant 13 online 
members of 560 total)

Same test with false took about 20 seconds to send all IMs

As my server is in europe, the 2 queries to the OSGrid group server AND 
the presence server can both be slow at times. This could be improved if 
the group service queries the presence server (as in most cases both 
will be within the same network) instead of the simulator sending both 
queries. So instead of the currently implemented proposal B, the 
proposal  C would be better for simulators further away or those with 
slow internet connection.


In addition, proposal C does not require each groupmember to be checked 
for online status if the group server uses a presence cache. Example, if 
2 people are sending IMs to diffrent groups with common members, then 1 
presence check would be enough for the common members, the lists of 
agents sent to the presence service would thus also be reduced. As in a 
bigger grids many IMs are beeing sent gridwide, the presence querries 
should  be even more efficiant in C compared to B




Yes, E is a hybrid of B/C and D. It could use the exact same online 
presence method as in B/C to get the list of online members. The group 
service would thus not realy need any changes. This also means, that a 
3rd party dev could develope the IM relay service which would then not 
need to be part of the core itself. The only change required would be 
simulator side, but even this would be a minor change. One would need to 
implement a url/enable ini setting, and depending on the setting the IM 
is sent simulator side or passed on to the IM relay service. Its a small 
change simulator side which should not be a problem for implementation 
in core.


As the IM relay server is an option, everyone can deside themselves if 
they trust the hoster of the IM relay service or if they want to have 
their own simulator send all IMs. Talking for the german cummunity in 
OSGrid, I know that we definatly will use a IM relay to improve the IM 
situation for the simulator side nomatter if A, B or C get implemented, 
especialy on our event regions.



 My personal favorit would be E, were C is the core group service and 
the optional IM+group notice Service can be run by closed grid admins or 
3rd party in open grids to improve worldwide groupchat and notice 
sending usage.






Am 08.11.2012 04:39, schrieb Justin Clark-Casey:
Hi Michelle.  Sorry that it's taken quite a long time for me to reply 
to this - unfortunately been hit by other work and divers alarums.


I somewhat edited [1] again, mainly for sense changes though I also 
left a few comments in italics.  To try and make things clearer, I 
gave the alternatives names (e.g. alternative E I've called "Separate 
group IM relay service".  Please change if these are not accurate.


It would seem that E is mostly a hybrid solution of B (simulator 
queries presence service on IM) and D (Groups service distributes 
IM)?  I would regard this as over-complicated for a core OpenSimulator 
solution, especially when one starts talking about trusted relay 
services.


I'm curious if you have tried the experimental MessageOnlineUsersOnly 
= true setting I added a couple of weeks ago.


[1] 
http://opensimulator.org/wiki/Feature_Proposals/Improve_Groups_Service


On 29/10/12 00:13, Michelle Argus wrote:
I have updated the proposal page and listed the diffrent alternative 
from A onwards sothat its easier for us.


My current favorite is the alternative E: The group server requests 
the online status from the grid server itself and
caches this data instead of the grid server keeping the group server 
updated.


-  Simulators request their data directly from the group server and 
sends IMs itself OR
- Optionaly the Simulator communicates via a relay service with its 
own cache. The relay service requests its data from
the same central group server. The relay service can additionaly send 
IMs if wanted to reduce resource usage simulator

side. The relay service can be hosted by anyone for a worldwide network.

The same concept could be used for other services such as assets, 
presence, inventory, friendslist etc which are
meanwhile causing many issues due to slow requests in bigger grids 
such as OSGrid.



Am 23.10.2012 04:40, schrieb Justin Clark-Casey:
Apologies, it's [1].   Please feel free to edit it as you see fit - 
I've put you as one of the proposers.  This page

is to keep track of the issue rather than a formal proposal mechanism.

No rush on this - please feel 

Re: [Opensim-dev] partially functional llSetKeyframedMotion implementation

[Mike Higgins]

I'm interested in helping with this project if there is a way that I can.
I'm not set up to build OpenSim, and I've been avoiding learning C# (I have too 
many hobbies already). But I implimented a single-frame version of 
llSetKeyframedMotion in LSL, and I can think in quaternions. I took a quick look 
at the code in your patch and I might be able to comment on the rotation math. 
Perhaps we should talk/chat/im sometime?




SignpostMarv Martin wrote:
I started work on an implementation of llSetKeyframedMotion at work the 
other day, but ran into some issues.


Would be nice if other devs could take a look and try to get it working? 
http://opensimulator.org/mantis/view.php?id=6112


I've only tested it with ping-pong translations (it goes too far when 
going backwards) and rotations are untested and known to be borked.



~ Marv.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev





No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.455 / Virus Database: 271.1.1/5295 - Release Date: 09/27/12 18:34:00





--
---
About the Internet, Obi Wan Kenobi had this to say:
"You will never find a more wretched hive of scum and villainy."
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Re: [Opensim-dev] BulletSim testing

[R.Gunther]

Why blog, this mailinglist works much better.

On 2012-11-08 05:32, OpenSimFan wrote:

maybe create a blog to explain things, and for users to share idea's...



-
_
Keep up the good work.!!! - OpenSimFan
My Opensim/Second Life Blog
http://verwijs.wordpress.com
(Dutch, basic hardware/software help  windows, Mac, Linux)
http://verwijs-pc.nl
My Twitter Page:
http://twitter.com/OpenSimFan
My Facebook page (be my friend, please )
http://www.facebook.com/andre.verwijs
--
View this message in context: 
http://opensim-dev.2196679.n2.nabble.com/BulletSim-testing-tp7578304p7578308.html
Sent from the opensim-dev mailing list archive at Nabble.com.
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev



___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev