The defaults should also work on low end server machines, I do not know if the physical prim limit is client size or server side.  <br><br><div class="gmail_quote">2012/10/17 Justin Clark-Casey <span dir="ltr"><<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Lani,<br>
<br>
As you know, we discussed this again in today's OpenSim dev OSGrid meeting.<br>
<br>
I think the general feeling among the developers was split.  Some were in favour of raising the limit, others want a bit more feedback from the 'real world' (i.e. people running regions with real object and script load).<br>

<br>
In particular, I would like to see more of this 'real world' feedback and/or more data on how physics FPS reacts to additional physics objects/linksets above the existing size limit.  As you say below, the tests you've already conducted mean that the proposal has already been reduced from the 64m number you were advocating last week to 32m, as physical fps drops dramatically with larger objects.  Even now, a 32m Torus causes a big physical fps reduction according to your graph [1].  I'd also like to know what happens with linksets which are inevitable if large vehicles are to be built.<br>

<br>
Teravus also expressed concerns at least weeks meeting with a 64m number since ODE divides the collision space into 10m (afair) parcels.  A larger prim straddles many of these and involves collision processing.  I don't know if he has any comment on a 32m limit.<br>

<br>
This isn't to say that I'm opposed to raising the limit - it's not as if OpenSimulator is short of things you can do to reduce performance and at this point simulator operators have to be able to deal with that to a certain extent.  And a higher limit may inspire physics improvements, particularly with BulletSim which operates differently and is used differently by OpenSimulator.<br>

<br>
However, my concern is that the limit isn't raised beyond what ODE can kind-of handle whilst it's the default physics engine.  New users of OpenSimulator should not be led to believe that large physical prims are currently possible if that results in a significant drop in physics performance.<br>

<br>
[1] <a href="http://opensimulator.org/wiki/User:LaniGlobal#Proposed_Change_Regions_ini_Default_PhysicalPrimMax_10m_to_64m" target="_blank">http://opensimulator.org/wiki/<u></u>User:LaniGlobal#Proposed_<u></u>Change_Regions_ini_Default_<u></u>PhysicalPrimMax_10m_to_64m</a><div>
<div class="h5"><br>
<br>
On 15/10/12 19:09, Amy Smith wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Dear OpenSim Devs,<br>
<br>
Date: 15 October 2012<br>
<br>
PROPOSAL TO CHANGE PhysicalPrimMax=32m<br>
This proposes a change to Regions.in file default parameter: PhysicalPrimMax=32m<br>
Old parameter was: PhysicalPrimMax=10m<br>
This parameter defines the maximum prim size limit (in any dimension x,y or z) at which the prim may be recognized by<br>
the region as a physical object. If any dimension of the prim is larger than this limit, the prim fails to become physical.<br>
<br>
DISCUSSION AT OPENSIM MEETING<br>
At the OpenSim Meeting last week in Wright Plaza OSGrid, I proposed changing the parameter default to PhysicalPrimMax=64m.<br>
However, after taking some data and doing some research testing various sizes and shapes of physical prims, I now<br>
propose PhysicalPrimMax=32m instead.<br>
<br>
BACKGROUND:<br>
The maximum prim build size using v1 viewers in SL was 10m, but this became obsolete recently with v2 and v3 viewers<br>
going to 64m. There has been *no limit* on the size of a physical prim in SL using their Havok physics engine. A<br>
mega-prim in SL can be physical (I have successfully tested 1024x1024x1024 physical prims in SL). However, in OpenSim<br>
there is good reason to limit physical prim size, mainly due to the simulator physics load causing simulator FPS to slow<br>
down.<br>
<br>
WHY CHANGE?<br>
Q: Why would we want to change this default value?<br>
A: The primary motivation for changing this is the growing popularity of PHYSICAL VEHICLES in OpenSim. Content creators<br>
for the OpenSim community must design their products for the most common default value limits.<br>
<br>
WHAT TYPES OF VEHICLES REQUIRE 32m PRIM SIZE?<br>
Built to-scale vehicles require prim sizes larger than 10metres: boats, ships, trains, buses, airplanes, aircraft,<br>
spacecraft, automobiles, and amphibious craft. Especially multi-passenger vehicles and vehicles using tortured prims or<br>
mesh or sculpties. Tortured prims (path cut, dimpled, tapered) are often used to achieve the curve shapes of vehicles,<br>
and this leads to larger prim x,y, or z dimensions (even when the overall vehicle size is less than 10metres). Mesh<br>
vehicles tend to require larger prim size; an entire vehicle can be made with 1 mesh model.<br>
<br>
BEST PARAMETER VALUE?<br>
32 metres is the proposed best parameter value. It is a compromise based on performance vs the value of having creative<br>
content. Certainly 10m prims are safe performance, however, 10m severely limits the existence of vehicle content.<br>
<br>
TEST RESULTS<br>
In recent testing of free prims dropped to ground, it was found that there appears to be a "breaking point" in the<br>
physics FPS performance with physical prim size larger than 45 metres. When 64 metre torus shaped prims were tested,<br>
this brought the physics FPS down to a low level. But, when 32metre prim size torus prims were tested, acceptably good<br>
performance was achieved. Of course, physics performance varies considerably among simulators.<br>
<br>
DATA:<br>
Please see collected data on size vs. shape on Physics FPS:<br>
<a href="http://opensimulator.org/wiki/User:LaniGlobal#Proposed_Change_Regions_ini_Default_PhysicalPrimMax_10m_to_64m" target="_blank">http://opensimulator.org/wiki/<u></u>User:LaniGlobal#Proposed_<u></u>Change_Regions_ini_Default_<u></u>PhysicalPrimMax_10m_to_64m</a><br>

<br>
CONCLUSION:<br>
A proposal has been presented for a default change. The change would be from an obsolete, but "absolutely safe" default<br>
value, to a new value that is closer to the center of compromise in simulator performance, only when larger size<br>
physical prims are rezzed by users. The result of this change would yield a huge increase in physical vehicle content in<br>
the OpenSim Community.<br>
<br>
Respectfully submitted,<br>
Lani Global<br>
(Amy Smith)<br>
<br>
Founder/Content Creator, LANI GLOBAL SYSTEMS (tm)<br>
Owner of Lani region of OSGrid, an OpenSim/HG 3-D Virtual Sci Fi World<br>
<a href="http://twitter.com/LaniGlobal" target="_blank">http://twitter.com/LaniGlobal</a><br>
hg.osgrid.org:80:lani<br>
<br>
<br>
<br>
<br>
.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br></div></div>
______________________________<u></u>_________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br>
<br><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
Justin Clark-Casey (justincc)<br>
OSVW Consulting<br>
<a href="http://justincc.org" target="_blank">http://justincc.org</a><br>
<a href="http://twitter.com/justincc" target="_blank">http://twitter.com/justincc</a><br>
______________________________<u></u>_________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Groningen en Hannover Opensims:  
<span style="color:rgb(50,61,86);font-family:'Trebuchet MS',Helvetia,Tahoma,Verdana,Arial,sans-serif;font-size:16px;text-align:left;background-color:rgb(255,255,255)">secondlife://meverhagen.nl:8002:Hannover ZW/ </span><br>