Difference between revisions of "Mesh/Download Weight"
Nyx Linden (talk | contribs) |
|||
Line 11: | Line 11: | ||
== Equation == | == Equation == | ||
# Compute the distance at which each LOD is displayed | # Compute the distance at which each LOD is displayed | ||
# Compute the | # Compute the area in which each LOD is relevant | ||
# Adjust for missiing LODs | # Adjust for missiing LODs | ||
# Compute cost based on relevant range and bytes in LOD | # Scale relative weights of each LOD based on what percentage of the region each LoD covers. | ||
# Compute cost based on relevant range and bytes in LOD | |||
=== LOD Transition Distances === | === LOD Transition Distances === | ||
Line 27: | Line 28: | ||
* Dmid = R / 1.0 | * Dmid = R / 1.0 | ||
* Dhigh = 0.0 | * Dhigh = 0.0 | ||
* lowest_circle = max area | |||
* low_circle = PI * Dlowest ^2 | |||
* mid_circle = PI * Dlow ^2 | |||
* high_circle = PI * Dmid^2 | |||
* lowest_area = lowest_circle - low_circle | |||
* low_area = low_circle - mid_circle | |||
* mid_area = mid_circle - high_circle | |||
* high_area = high_circle | |||
=== Relevant LOD Ranges === | === Relevant LOD Ranges === | ||
Line 44: | Line 55: | ||
==== Computing Cost ==== | ==== Computing Cost ==== | ||
Streaming Cost = | Streaming Cost = | ||
( | ( (lowest_area / total_area) * kbytes_in_lowest + <br> | ||
(low_area / total_area) * kbytes_in_low + <br> | |||
(mid_area / total_area) * kbytes_in_mid + <br> | |||
(high_area / total_area) * kbytes_in_high ) * cost_scalar | |||
==== Cost Scaler ==== | ==== Cost Scaler ==== | ||
Cost scaler is currently 0.125. | Cost scaler is currently 0.125. | ||
=== Implementation === | === Implementation === |
Revision as of 14:21, 14 June 2011
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
Previously used methods of LOD enforcement and mesh cost have proved ineffective and difficult to adhere to. Proposed here is an algorithm for determining cost of a mesh asset (in terms of prim parcel cost) that correlates strongly to the actual load of streaming and displaying a mesh in a general way, without making assumptions about triangle/vertex limits and ratios between levels of detail. The artist need not adhere to any arbitrary restrictions with respect to what LODs must be supplied and what the parameters of those LODs are, but providing proper LODs will greatly reduce the cost of an object in terms of parcel limits, effectively allowing regions with efficient content to carry more content, while regions with inefficient content can carry less. This should allow greater control from Linden Lab in terms of acceptable rendering and streaming budgets while also giving artists complete control over how they build.
Concept
The streaming and rendering cost of a mesh is directly related to the number of bytes in a mesh asset LOD slot, and the likelihood that a given LOD will be downloaded and displayed can be computed based on the size of the object. Imagine a set of 3 concentric circles centered on an object where each circle represents the transition boundary between LODs. The streaming/rendering cost of that object can be determined by examining the size of those circles vs the number of bytes in the relevant LODs. Uploading a high LOD only will result in the load of the high lod being applied to the entire 256m, while uploading appropriate LODs will result in the lion's share of 256m being applied to the lowest LOD
Equation
- Compute the distance at which each LOD is displayed
- Compute the area in which each LOD is relevant
- Adjust for missiing LODs
- Scale relative weights of each LOD based on what percentage of the region each LoD covers.
- Compute cost based on relevant range and bytes in LOD
LOD Transition Distances
To compute the distance at which each LOD is displayed, take the radius of the object's bounding box (R) and divide by the LOD ratios used in the viewer:
- Dlowest = distance at which lowest LOD begins to be displayed
- Dlow = distance at which low LOD begins to be displayed
- Dmid = distance at which mid LOD begins to be displayed
- Dhigh = distance at which high LOD begins to be displayed
- Dlowest = R / 0.06
- Dlow = R / 0.24
- Dmid = R / 1.0
- Dhigh = 0.0
- lowest_circle = max area
- low_circle = PI * Dlowest ^2
- mid_circle = PI * Dlow ^2
- high_circle = PI * Dmid^2
- lowest_area = lowest_circle - low_circle
- low_area = low_circle - mid_circle
- mid_area = mid_circle - high_circle
- high_area = high_circle
Relevant LOD Ranges
The relevant range of each LOD is the distance between which that LOD becomes visible and the distance at which that LOD is no longer displayed, clamped to a 256m circle.
Example: For an object with a bounding box R of 10m, The Dhigh LOD will be displayed while the camera is within 0m to 10m from the object's center. The Dmid LOD will be displayed while the camera is within 10m to 41.67m (10/0.24) from the object's center. The Dlow LOD will be displayed while the camera is within 41.67m to 166.37m from the object's center. The Dlowest LOD will be displayed while the camera is within 166.37m to 256m from the object's center.
Adjusting for missing LODs
if any lod is missing, substitute bytes in next highest available LOD. That is, if BYTES_IN_MID is zero, substitute BYTES_IN_HIGH for BYTES_IN_MID, and so on
Computing Cost
Streaming Cost =
( (lowest_area / total_area) * kbytes_in_lowest +
(low_area / total_area) * kbytes_in_low +
(mid_area / total_area) * kbytes_in_mid +
(high_area / total_area) * kbytes_in_high ) * cost_scalar
Cost Scaler
Cost scaler is currently 0.125.
Implementation
F32 LLMeshRepository::getStreamingCost(const LLSD& header, F32 radius) { F32 dlowest = llmin(radius/0.06f, 256.f); F32 dlow = llmin(radius/0.24f, 256.f); F32 dmid = llmin(radius/1.0f, 256.f); F32 bytes_lowest = header["lowest_lod"]["size"].asReal()/1024.f; F32 bytes_low = header["low_lod"]["size"].asReal()/1024.f; F32 bytes_mid = header["medium_lod"]["size"].asReal()/1024.f; F32 bytes_high = header["high_lod"]["size"].asReal()/1024.f; if (bytes_high == 0.f) { return 0.f; } if (bytes_mid == 0.f) { bytes_mid = bytes_high; } if (bytes_low == 0.f) { bytes_low = bytes_mid; } if (bytes_lowest == 0.f) { bytes_lowest = bytes_low; } F32 max_area = 65536.f; F32 min_area = 1.f; F32 high_area = llmin(F_PI*dmid*dmid, max_area); F32 mid_area = llmin(F_PI*dlow*dlow, max_area); F32 low_area = llmin(F_PI*dlowest*dlowest, max_area); F32 lowest_area = max_area; lowest_area -= low_area; low_area -= mid_area; mid_area -= high_area; high_area = llclamp(high_area, min_area, max_area); mid_area = llclamp(mid_area, min_area, max_area); low_area = llclamp(low_area, min_area, max_area); lowest_area = llclamp(lowest_area, min_area, max_area); F32 total_area = high_area + mid_area + low_area + lowest_area; high_area /= total_area; mid_area /= total_area; low_area /= total_area; lowest_area /= total_area; F32 weighted_avg = bytes_high*high_area + bytes_mid*mid_area + bytes_low*low_area + bytes_lowest*lowest_area; return weighted_avg * gSavedSettings.getF32("MeshStreamingCostScaler"); }
Issues
- Providing identical models for every LOD results in a cost identical to providing a single LOD, but results in 4x the bandwidth usage.
- Changing the scale of an object changes its cost, which can be confusing.
- For viewers with a view distance greater than 256m, the clamping to 256m is unrealistic.
- Some validating of LODs is still necessary.
- The highest LOD must be specified
- Each LOD must have the same number of faces as the highest LOD