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 <[email protected]> > 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 >> [email protected] >> 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 > [email protected] > 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/
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
