[Opensim-dev] PhysicalPrimMax=32m Proposal: Regions.ini Default

Wed Oct 17 09:40:51 UTC 2012

If I recall, the limits are used to clamp calls to llSetScale() & similar.

There may be a small amount of content that assumes it'll get clamped to 
10m rather than the new value.

~ Marv.

On 17/10/2012 01:01, Justin Clark-Casey wrote:
> Dear Lani,
>
> As you know, we discussed this again in today's OpenSim dev OSGrid 
> meeting.
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> [1] 
> http://opensimulator.org/wiki/User:LaniGlobal#Proposed_Change_Regions_ini_Default_PhysicalPrimMax_10m_to_64m
>
> On 15/10/12 19:09, Amy Smith wrote:
>> Dear OpenSim Devs,
>>
>> Date: 15 October 2012
>>
>> PROPOSAL TO CHANGE PhysicalPrimMax=32m
>> This proposes a change to Regions.in file default parameter: 
>> PhysicalPrimMax=32m
>> Old parameter was: PhysicalPrimMax=10m
>> This parameter defines the maximum prim size limit (in any dimension 
>> x,y or z) at which the prim may be recognized by
>> the region as a physical object. If any dimension of the prim is 
>> larger than this limit, the prim fails to become physical.
>>
>> DISCUSSION AT OPENSIM MEETING
>> At the OpenSim Meeting last week in Wright Plaza OSGrid, I proposed 
>> changing the parameter default to PhysicalPrimMax=64m.
>> However, after taking some data and doing some research testing 
>> various sizes and shapes of physical prims, I now
>> propose PhysicalPrimMax=32m instead.
>>
>> BACKGROUND:
>> The maximum prim build size using v1 viewers in SL was 10m, but this 
>> became obsolete recently with v2 and v3 viewers
>> going to 64m. There has been *no limit* on the size of a physical 
>> prim in SL using their Havok physics engine. A
>> mega-prim in SL can be physical (I have successfully tested 
>> 1024x1024x1024 physical prims in SL). However, in OpenSim
>> there is good reason to limit physical prim size, mainly due to the 
>> simulator physics load causing simulator FPS to slow
>> down.
>>
>> WHY CHANGE?
>> Q: Why would we want to change this default value?
>> A: The primary motivation for changing this is the growing popularity 
>> of PHYSICAL VEHICLES in OpenSim. Content creators
>> for the OpenSim community must design their products for the most 
>> common default value limits.
>>
>> WHAT TYPES OF VEHICLES REQUIRE 32m PRIM SIZE?
>> Built to-scale vehicles require prim sizes larger than 10metres: 
>> boats, ships, trains, buses, airplanes, aircraft,
>> spacecraft, automobiles, and amphibious craft. Especially 
>> multi-passenger vehicles and vehicles using tortured prims or
>> mesh or sculpties. Tortured prims (path cut, dimpled, tapered) are 
>> often used to achieve the curve shapes of vehicles,
>> and this leads to larger prim x,y, or z dimensions (even when the 
>> overall vehicle size is less than 10metres). Mesh
>> vehicles tend to require larger prim size; an entire vehicle can be 
>> made with 1 mesh model.
>>
>> BEST PARAMETER VALUE?
>> 32 metres is the proposed best parameter value. It is a compromise 
>> based on performance vs the value of having creative
>> content. Certainly 10m prims are safe performance, however, 10m 
>> severely limits the existence of vehicle content.
>>
>> TEST RESULTS
>> In recent testing of free prims dropped to ground, it was found that 
>> there appears to be a "breaking point" in the
>> physics FPS performance with physical prim size larger than 45 
>> metres. When 64 metre torus shaped prims were tested,
>> this brought the physics FPS down to a low level. But, when 32metre 
>> prim size torus prims were tested, acceptably good
>> performance was achieved. Of course, physics performance varies 
>> considerably among simulators.
>>
>> DATA:
>> Please see collected data on size vs. shape on Physics FPS:
>> http://opensimulator.org/wiki/User:LaniGlobal#Proposed_Change_Regions_ini_Default_PhysicalPrimMax_10m_to_64m 
>>
>>
>> CONCLUSION:
>> A proposal has been presented for a default change. The change would 
>> be from an obsolete, but "absolutely safe" default
>> value, to a new value that is closer to the center of compromise in 
>> simulator performance, only when larger size
>> physical prims are rezzed by users. The result of this change would 
>> yield a huge increase in physical vehicle content in
>> the OpenSim Community.
>>
>> Respectfully submitted,
>> Lani Global
>> (Amy Smith)
>>
>> Founder/Content Creator, LANI GLOBAL SYSTEMS (tm)
>> Owner of Lani region of OSGrid, an OpenSim/HG 3-D Virtual Sci Fi World
>> http://twitter.com/LaniGlobal
>> hg.osgrid.org:80:lani
>>
>>
>>
>>
>> .
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>
>