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