Difference between revisions of "Mesh/Mesh Server Weight"

Revision as of 10:41, 15 April 2014

Mesh

Basics

Advanced

Project Information

READ THIS FIRST

This is a preliminary design of an unimplemented cost algorithm. EVERYTHING is subject to change, and certainly will change, during the course of implementation.

Motivation

The server must track all pieces, or prims, in the region at all times. As such every individual piece, or prim, has a certain cost to the server regardless of its physical or visual complexity. There are, however, some factors that make an object more or less expensive for the server to track: in particular truly passive objects that are not scripted or physical are much easier to track than scripted or physical objects.

Concept

There are two basic goals for this cost:

The maximum server load from objects should not increase from mesh content.
Allow more passive content than before.

Equation

Important: This section is out of date and needs an edit. See Release Notes/Second Life Server/12#12.07.31.262785, the revised formula is
MIN{ (0.5*num_prims) + (0.25 * num_scripts), num_prims }

Take the number of prims in the object.
If the object contains no scripts and is not physical: divide by static_bonus

per_prim_cost = 1.0
static_bonus = 2.0
cost_scalar = 1.0

The static_bonus only applies if the object is not physical and contains no scripts.

Server weight per prim: cost_scalar * (per_prim_cost / static_bonus)

Examples

Prims	Scripted Or Physical	Server Cost	Non-Mesh Cost
1	No	1	1
1	Yes	1	1
10	No	5	10
10	Yes	10	10
30	No	15	30
30	Yes	30	30

How To Optimize

Consolidate mesh shapes such that the individual uploaded meshes are as complete as possible.
- A more complete mesh will generally have a streaming cost of several PE and not be server bound.
Separate static content from dynamic content when possible.

@@ Line 4: / Line 4: @@
 == Motivation ==
-Different pieces of content affect server load in a variety of ways. An object that may appear simple to display and have a simple physics representation may cause significantly more load on a simulator than other pieces of content that appear more complex. Having all prims charged the same amount regardless of how much load they put on the simulator doesn't give content creators the proper feedback for optimizing their designs.
+The server must track all pieces, or prims, in the region at all times. As such every individual piece, or prim, has a certain cost to the server regardless of its physical or visual complexity. There are, however, some factors that make an object more or less expensive for the server to track: in particular truly passive objects that are not scripted or physical are much easier to track than scripted or physical objects.
+== Concept ==
+There are two basic goals for this cost:
+* The maximum server load from objects should not increase from mesh content.
+* Allow more passive content than before.
+== Equation ==
+{{KBcaution|This section is out of date and needs an edit. See [[Release Notes/Second Life Server/12#12.07.31.262785]], the revised formula is<br/>'''MIN{ (0.5*num_prims) + (0.25 * num_scripts), num_prims }''' }}
-== Concept ==
+# Take the number of prims in the object.
-Server load from an object can be approximated by the number of messages that are generated from the object. The more object updates that a piece of content generates, the more data handling and processing the server has to do in order to keep all avatars in the area up to date with the object's current status. When prims are linked together into a single object, there are some per-object messages that need to be handled, and some per-prim messages. Additionally, some pieces of content are far more likely to generate more messages - such as scripted or physical objects
+# If the object contains no scripts and is not physical: divide by static_bonus
+* ''per_prim_cost'' = 1.0<br>
+* ''static_bonus'' = 2.0<br>
+* ''cost_scalar'' = 1.0
+The ''static_bonus'' only applies if the object is not physical and contains no scripts.
+Server weight per prim: ''cost_scalar'' * (''per_prim_cost'' / ''static_bonus'')
-== Equation ==
+== Examples ==
-# Take a base cost per object
-# Add a cost per prim in object * number of prims
-# Multiply by an "active" multiplier if object is dynamic (physical or scripted)
-== Computing Cost ==
+{| border="1" cellpadding="3" cellspacing="0"
-dynamic_multiplier = 2.0 <br>
+! align="right"| Prims
-static_multiplier = 1.0 <br>
+! Scripted Or
-per_prim_cost = 0.5 <br>
+Physical
-base_cost = 1.0 <br>
+! Server
+Cost
+! Non-Mesh
+Cost
+|-
+|align="right"|1
+|align="center"|No
+|align="right"|1
+|align="right"|1
+|-
+|align="right"|1
+|align="center"|Yes
+|align="right"|1
+|align="right"|1
-if there are any scripts or the object is physical, active_cost = dynamic_multiplier. Otherwise active_cost = static_multiplier.
+|-
+|align="right"|10
+|align="center"|No
+|align="right"|5
+|align="right"|10
+|-
+|align="right"|10
+|align="center"|Yes
+|align="right"|10
+|align="right"|10
-Cost scaler is currently 1.0
+|-
+|align="right"|30
+|align="center"|No
+|align="right"|15
+|align="right"|30
+|-
+|align="right"|30
+|align="center"|Yes
+|align="right"|30
+|align="right"|30
+|}
-Server weight(per prim) = cost_scalar * (active_cost * (per_prim_cost + base_cost / num_prims)
+== How To Optimize ==
+* Consolidate mesh shapes such that the individual uploaded meshes are as complete as possible.
+** A more complete mesh will generally have a streaming cost of several PE and not be server bound.
+* Separate static content from dynamic content when possible.