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

Wed Oct 17 07:10:43 UTC 2012

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.

2012/10/17 Justin Clark-Casey <jjustincc at googlemail.com>

> 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<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<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<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 at lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>

-- 
Groningen en Hannover Opensims:   secondlife://meverhagen.nl:8002:Hannover
ZW/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20121017/b206f565/attachment-0001.html>