Difference between revisions of "Mesh/Mesh physics"
Dan Linden (talk | contribs) |
|||
(7 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{Navbox/Mesh}} | {{Navbox/Mesh|tech}} | ||
This article explains the physics behavior of imported mesh objects and, to a lesser extent, triangle-based prims under new accounting | |||
== Mesh Assets: Physics Shapes and Decompositions == | == Mesh Assets: Physics Shapes and Decompositions == | ||
Line 36: | Line 34: | ||
Exceptions: | Exceptions: | ||
#A non-physical prim which is moving (e.g., via llSetVelocity) is treated as dynamic until all motion has ceased for several frames | #A non-physical prim which is moving (e.g., via llSetVelocity or being grabbed) is treated as dynamic until all motion has ceased for several frames | ||
Notes: | Notes: | ||
Line 47: | Line 45: | ||
== Physics Resource Cost == | == Physics Resource Cost == | ||
There will be a new physics-based resource cost (PRC) computation. It will be used directly in determining whether objects can be made physical and will be a factor in determining total prim resource cost for a parcel or region. | There will be a new physics-based resource cost (PRC) computation. It will be used directly in determining whether objects can be made physical and will be a factor in determining total prim resource cost for a parcel or region. | ||
=== Opt-In === | |||
A prim or linkset will have a physics resource cost (PRC) computed if and only if it contains: | |||
* A mesh asset | |||
OR | |||
* A prim with a physics shape type other than "Prim". | |||
=== Formula === | |||
[[Image:PhysicsResourceCostEqn.png]] | |||
'''Notes''': | |||
'''The third term in the above equation (the one governing triangle mesh cost) is no longer correct.''' The actual math is now substantially more complex but the result is easier to understand. | |||
''Triangle Mesh Overview'' | |||
Briefly, the cost of a physics triangle mesh now depends on two things: (1) The number of triangles and (2) The "average width" of those triangles at the mesh's current scale. The width of a triangle is defined as the width (smaller side) of the tightest rectangle you can draw around the triangle. The average is computed "harmonically" (1/avg = 1/a + 1/b + ... ), which was done to favor weight smaller triangles more heavily. This average is then clamped to be between 0.001m and 20m (right now) and then used in the simple formula: | |||
C = MAX( constant * num_triangles / triangle_width, minimum_mesh_cost ) | |||
The value of "constant" has been selected so that for a flat mesh with 0.5m wide triangles, each triangle costs 0.1 units with a minimum total mesh cost of 0.5 units. However, these values are subject to change. | |||
Please note that the computed triangle_width is only an APPROXIMATION of the exact triangle width in most cases. | |||
* | IMPORTANT: For triangle-based shapes, the cost grows inversely with the scale of the prim! More specifically, it varies linearly with triangle density. This is important as triangle density has a huge impact on physics performance. Also note that for large meshes, the density multiplier may be less than unity, resulting in a discounting effect. | ||
The resulting number may not be an integer. A prim with physics shape type "none" does not contribute to the pure PRC! | |||
'''NEW''' | |||
An additional factor has been added to this computation. If a linkset is made physical, it will incur an additional penalty that will depend on its scale. The formula is: | |||
penalized_cost = base_physics_cost * ( 1 + 0.04 * A ) | |||
where A is the the mean face area of the linkset's axis aligned bounding box (defined by its overall scale). Here's an example to make it clear | |||
* Create a linkset consisting of 10 boxes. Set one of them to have shape type Convex Hull (to trigger the new accounting) | |||
* Arrange them and scale the linkset so that the overall linkset scale is 3m x 4m x 5m | |||
* Since the linkset contains 10 boxes and is a new accounting linkset, its base physics cost is 10 * 0.1 = 1 prim equivalent | |||
* Now, make the linkset physical. Since we scaled the linkset to 3 x 4 x 5, its bounding box has faces of 12m^2 (3 * 4), 20m^2 (4 * 5), and 15m^2 (3 * 5). The average face area is therefore (12 + 20 + 15)/3 = 15.7. | |||
* penalized_cost = 1 * ( 1 + 0.04 * 15.7 ) = 1.628, or 2 prims after rounding | |||
Another quick example: | |||
* Import/upload the duck model using a physics decomposition. Let's say the resulting decomposition has a physics cost of 13 prim equivalents (it did in my experiment) | |||
* After setting the duck to "PRIM" so that it uses the decomposition, the cost is 13 | |||
* Scale the duck to 10m x 10m x 10m. Its physics cost is still 13 | |||
* Set the duck Physical. It average face size is 100m^2, so the penalized_cost = 13 * ( 1 + 0.04 * 100 ) = 13 * 5 = 65 prim equivalents. | |||
Note that the penalized cost does NOT affect whether the object can be made physical in the first place. Rest assured that if your linkset has a physics weight of <32.0 prim equivalents when NOT physical you will still be able to set it physical. Of course, if doing so results in the cost going up, something on your parcel may be returned to you if you are over your resource quota. | |||
===Simulator resource cost (SRC)=== | |||
Simulator resource cost (SRC) reflects the cost of "managing" a linkset or prim. For example, this includes things like sending out updates about the object's state to relevant viewers. | |||
* | SRC = simulation_factor * active_cost * ( num_objects + (linkset_factor/num_objects) ) | ||
* simulation_factor and linkset_factor are constants for tuning the overall cost. | |||
* active_cost is always either active_cost_high or active_cost_low (two additional tuning constants). The high value is used if the object is scripted, physics-enabled, or both. | |||
What this means is that to minimize SRC, you should: | |||
If | # Group your prims into as few linksets as possible | ||
# Minimize the number of linksets you need to script or make physical | |||
# Minimize the number of unlinked or small linksets | |||
# If an object is physical or scripted, keep its linkset as small as possible (but don't create multiple scripted unlinked prims instead!) | |||
===Region resource cost (RRC)=== | |||
Regions and parcel limits for prims/linksets will use the | Regions and parcel limits for prims/linksets will use the region resource cost which is the greater of the SRC and the bandwidth resource cost (also known as streaming resource cost, described elsewhere). |
Latest revision as of 12:21, 4 August 2011
This article explains the physics behavior of imported mesh objects and, to a lesser extent, triangle-based prims under new accounting
Mesh Assets: Physics Shapes and Decompositions
A valid mesh asset will contain:
- A single convex hull with no more than 256 vertices
- All assets will contain a single convex hull with no more than 256 verts that will be used:
- If the physics shape type is set to "Convex Hull"
- If there is no decomposition and the prim is in motion of any kind
- All assets will contain a single convex hull with no more than 256 verts that will be used:
- (Optional) An additional convex decomposition containing up to 256 vertices per hull and up to 256 hulls
- (Optional) A mesh designated specifically for use in the physics engine
Mesh Asset Header Identifiers
- "physics_shape" - optional, reference to mesh to be used in place of visible mesh for collisions
- "decomposition" - required, reference to one or more convex hulls of no more than 256 vertices each to be used in place of physical mesh
Decomposition Data Block Members
- "Min"/"Max" - required, LLVector3, floating point domain to decode binary U16 data to
- "HullList" - optional, binary U8, list of point counts of hulls stored in "Position". '0' is special cased to indicate 256 points.
- "Position" - optional, binary U16, list of positions of points in hulls that make up the multi-hull decomposition of this mesh
- "Hull" - required, binary U16, list of positions in a single convex hull of no more than 256 verts that wraps entire physical mesh
- "Hull" is generated automatically at upload time by feeding the physics shape, mid lod, or high lod into LLConvexDecomposition:
- Stage 1: Mode set to "Preview"
- Stage 2: Simplify mode set to "Retain%", retain percentage set to zero.
- "Hull" is generated automatically at upload time by feeding the physics shape, mid lod, or high lod into LLConvexDecomposition:
Physics Representation for Rezzed Prims
Exceptions:
- A non-physical prim which is moving (e.g., via llSetVelocity or being grabbed) is treated as dynamic until all motion has ceased for several frames
Notes:
- Meshes should initially rez with shape type "Convex Hull" as the physics resource cost (see below) for detailed physics meshes may be very high and depends on the prim's scale
- A mesh object uploaded without an explicit physics shape or decomposition cannot be changed to shape type prim and will always be represented as a single convex hull bounding the mesh.
- At any time prior to release to Agni, we may choose to require a physics mesh be provided
- No linkset or prim with a pure physics resource cost exceeding 32.0 may be set physical
Physics Resource Cost
There will be a new physics-based resource cost (PRC) computation. It will be used directly in determining whether objects can be made physical and will be a factor in determining total prim resource cost for a parcel or region.
Opt-In
A prim or linkset will have a physics resource cost (PRC) computed if and only if it contains:
- A mesh asset
OR
- A prim with a physics shape type other than "Prim".
Formula
Notes:
The third term in the above equation (the one governing triangle mesh cost) is no longer correct. The actual math is now substantially more complex but the result is easier to understand.
Triangle Mesh Overview Briefly, the cost of a physics triangle mesh now depends on two things: (1) The number of triangles and (2) The "average width" of those triangles at the mesh's current scale. The width of a triangle is defined as the width (smaller side) of the tightest rectangle you can draw around the triangle. The average is computed "harmonically" (1/avg = 1/a + 1/b + ... ), which was done to favor weight smaller triangles more heavily. This average is then clamped to be between 0.001m and 20m (right now) and then used in the simple formula:
C = MAX( constant * num_triangles / triangle_width, minimum_mesh_cost )
The value of "constant" has been selected so that for a flat mesh with 0.5m wide triangles, each triangle costs 0.1 units with a minimum total mesh cost of 0.5 units. However, these values are subject to change.
Please note that the computed triangle_width is only an APPROXIMATION of the exact triangle width in most cases.
IMPORTANT: For triangle-based shapes, the cost grows inversely with the scale of the prim! More specifically, it varies linearly with triangle density. This is important as triangle density has a huge impact on physics performance. Also note that for large meshes, the density multiplier may be less than unity, resulting in a discounting effect.
The resulting number may not be an integer. A prim with physics shape type "none" does not contribute to the pure PRC!
NEW An additional factor has been added to this computation. If a linkset is made physical, it will incur an additional penalty that will depend on its scale. The formula is:
penalized_cost = base_physics_cost * ( 1 + 0.04 * A )
where A is the the mean face area of the linkset's axis aligned bounding box (defined by its overall scale). Here's an example to make it clear
- Create a linkset consisting of 10 boxes. Set one of them to have shape type Convex Hull (to trigger the new accounting)
- Arrange them and scale the linkset so that the overall linkset scale is 3m x 4m x 5m
- Since the linkset contains 10 boxes and is a new accounting linkset, its base physics cost is 10 * 0.1 = 1 prim equivalent
- Now, make the linkset physical. Since we scaled the linkset to 3 x 4 x 5, its bounding box has faces of 12m^2 (3 * 4), 20m^2 (4 * 5), and 15m^2 (3 * 5). The average face area is therefore (12 + 20 + 15)/3 = 15.7.
- penalized_cost = 1 * ( 1 + 0.04 * 15.7 ) = 1.628, or 2 prims after rounding
Another quick example:
- Import/upload the duck model using a physics decomposition. Let's say the resulting decomposition has a physics cost of 13 prim equivalents (it did in my experiment)
- After setting the duck to "PRIM" so that it uses the decomposition, the cost is 13
- Scale the duck to 10m x 10m x 10m. Its physics cost is still 13
- Set the duck Physical. It average face size is 100m^2, so the penalized_cost = 13 * ( 1 + 0.04 * 100 ) = 13 * 5 = 65 prim equivalents.
Note that the penalized cost does NOT affect whether the object can be made physical in the first place. Rest assured that if your linkset has a physics weight of <32.0 prim equivalents when NOT physical you will still be able to set it physical. Of course, if doing so results in the cost going up, something on your parcel may be returned to you if you are over your resource quota.
Simulator resource cost (SRC)
Simulator resource cost (SRC) reflects the cost of "managing" a linkset or prim. For example, this includes things like sending out updates about the object's state to relevant viewers.
SRC = simulation_factor * active_cost * ( num_objects + (linkset_factor/num_objects) )
- simulation_factor and linkset_factor are constants for tuning the overall cost.
- active_cost is always either active_cost_high or active_cost_low (two additional tuning constants). The high value is used if the object is scripted, physics-enabled, or both.
What this means is that to minimize SRC, you should:
- Group your prims into as few linksets as possible
- Minimize the number of linksets you need to script or make physical
- Minimize the number of unlinked or small linksets
- If an object is physical or scripted, keep its linkset as small as possible (but don't create multiple scripted unlinked prims instead!)
Region resource cost (RRC)
Regions and parcel limits for prims/linksets will use the region resource cost which is the greater of the SRC and the bandwidth resource cost (also known as streaming resource cost, described elsewhere).