Nyx Linden

That would be a fairly trivial code change, I can bring up the possibility with our UI designer.

There's at least one instance of incorrect PE numbers being displayed - see https://jira.secondlife.com/browse/CTS-643 If there are more instances where the wrong values are displayed, definitely let us know!

ARC is not accurate for meshes. Using individeual tiny pieces to build up jewelry is probably not going to be terribly economical from a cost perspective. We can only LOD each individual mesh "prim", so a linkset of hundreds of small mesh prims can only be reduced in triangle count so low, which is the same issue we have with jewelry in SL today. I'd encourage jewelry makers who want to use mesh to make complete pieces in their modelers, rather than creating each gem or chain link and assembling in-world.

Nice chart! Display weight is currently a highly inaccurate algorithm and has no impact on the prim equivalency. PE should be displayed if it differs from the prim count (thus is not redundant information). Number 5 definitely sounds like a bug to me!

As documented here: https://wiki.secondlife.com/wiki/Mesh/Costs_and_fees Making an object that uses the new accounting system be scripted or making it physical will cause the object to be referred to as 'dynamic'. This means that we believe that the object is more likely to generate ObjectUpdate messages to the surrounding users, which impacts the amount of work the server has to do. It is a very rough calculation as it is not possible to predict how many messages a particular object is bound to generate over a period of time. Please note that this means that the "server weight" of an object is not meant to approximate the amount of script time or memory that an object uses up, only how likely it is to cause changes that will impact the message queue. Please note that whether an object (aka linkset) is "dynamic" is a binary value. It does not depend on the number of scripts in an object, or whether its physical *and* scripted or just one of the two. Also note that this will only impact the server weight portion of the computation. Thus, whether an object is scripted or not will not affect the "prim equiv" value of an object that causes more stress on the physics or download (streaming) aspects of the system. This is why you're seeing an impact with small, standalone objects that are not geometrically complex, but it is not affecting more complicated objects (linksets).

Official (server-generated) numbers are provided for "prim equiv" and "physics weight". The debug info display for streaming cost should be accurate on release, but it is viewer-generated and thus may be inaccurate. There is not currently a debug display for server weight specifically. We're looking into what it would take to provide more detailed information after the initial release.

"Display weight" is really just a relabeld "render cost". That's our new term for it and its currently displayed for informational purposes only. Before we can start to limit display weight, we will need to switch to the new algorithm, get the new algorithm on the simulator, and do a fair bit of tweaking so that the numbers are scaled appropriately. Currently "display weight" should just be the amount your ARC will increase if you attach the object. If this is not the case, its a bug, and let me know about it. The minimum for a single isolated mesh is indeed the server weight. If you look at the documentation you can see we charge 1 prim for the object as a whole and 0.5 prims for each piece. So an isolated mesh object will cost 2 if its streaming cost is low, but the per-prim cost is only 0.5. The values are rounded to the nearest prim.

If the streaming weight is the highest weight of the three, the prim equivelancy will be equal to the streaming weight. In that case the server cost will be irrelevant for the currently implemented system.

We've actually had quite a few discussions on terms and vocabulary. First of all, PE weight is indeed "Prim Equivalent" weight. It is the number of "prims" of land capacity used by the object and should be the highest of the three metrics we measure content on. We are avoiding labeling this value as "cost" as that gets too closely conflated with the "fee" charged on upload. The term "object" has generally referred to a linkset in our UI and documentation, which is distinct from a "prim" which is the smallest divisible unit in a linkset. The definition of "prim" is being extended to include mesh prims, just as sculpted prims are still referred to as prims. Builders should be able to enable a more comprehensive view (showing physics weight and render weight) by enabling the debug option "ShowAdvancedBuilderOptions". it is being displayed as zero objects because you do not have a full object/linkset selected. I can see how this could be confusing. Suggestions on what to show when a partial object is selected appreciated! This is the first checkin of the new layout, I'm not surprised there is some confusion and probably some bugs. Definitely keep pointing out where the holes are so we can patch them up before release! Thanks! -Nyx

Any prim in a linkset with a mesh or a prim that uses a non-default physics shape type will be evaluated according to the metric "weights" (Download, Server, and Physics). Whether a primitive object should be evaluated with the old system (a prim is a prim), or based on its qualities is determined at the linkset/object level, not at the individual primitive level. See http://community.secondlife.com/t5/Mesh/Calculating-quot-Prim-Equivalency-quot/td-p/937343 We hope to get the wiki documentation up to date on this matter soon, keep an eye on https://wiki.secondlife.com/wiki/Mesh/Costs_and_fees

We would have to compensate for the render load in some way, and ideally we'd have to take advantage of hardware instancing. Either way we cannot enable discounts for instancing for the initial release.

ideally this would be beneficial, but currently we don't have the infrastructure for this level of optimization. Would be nice to give a discount in the future for this level of optimization, but not a strict requirement for the initial release.

Can you clarify what you want to use such a small object for? When working with prims, such prims were used to add tiny details to larger objects, as the prim was the smallest unit one could work with. With meshes, you should be able to put in such details with a few extra triangles in the highest LOD. What is your usecase for needing to generate a mesh object that is smaller than a centimeter on a side?

Linkset (Object) cost should be the one that you are actually charged against. We're going to be cleaning up our build tools display of data soon hopefully. The only difference between the two should be that the linkset cost should be rounded from the total prim cost for a single object.

Greetings all! There's been a bit of confusion around how we deecide how many "prims" a given mesh is equivalent to, so I wanted to take a moment to go over the system from a high-level view to try to clear up some of the confusion. Prims that are subject to these rules fall under one of the following categories: 1) Its a mesh 2) It uses the new physics shape type 3) It is linked to #1 or #2 Anything else will fall under the legacy system of 1 prim = 1 prim.   For content under the new system, we measure the content against three metrics (or "weights"). These are: Download weight, Physics weight, and Server Weight. Once these values are computed, we take whichever one is highest and treat that (rounded) as the number of prims charged against your land's budget. Download (streaming) weight depends mainly on the number of triangles in a primitive (mesh or not), as well as its physical size. This is to account for approximately how complex the object will be to download & draw at various distances from the object. Physics weight depends on the physics representation used (prim, convex hull, none), as well as how complex that representation is. Note that "Prim" physics shape type could refer to an uploaded convex decomposition, or an undecomposed physics mesh. Server Weight tries to approximate the amount of messages that a given object will generate on the server that has to be passed to observers. There is a per-object (linkset), as well as a per-primitive cost (a single unlinked prim counts as both). Physical and scripted objects generate significantly more messages than static content, and thus are charged more in server cost. Please note that the different weights are computed completely independently. Specifically that means that adding a script or making an object physical will affect the Server weight, but will have no effect on the Download weight.   I'll be working on trying to update / keep up to date the costs and fees page with the latest information. https://wiki.secondlife.com/wiki/Mesh/Costs_and_fees   Please note that we are still working on adjusting the exact numbers being generated by each system, so if you have content that seems too heavy or too light in terms of prim equivalence please send it in. We believe the current structure should be a straightforward system for the first release, though we reserver the right to make changes as appropriate in the future. Please let us know if you have questions!    -Nyx  

Known issue, we have an internal jira for htis already. I'm looking into it - appears that our latest build of collada on linux is unstable.

We should already be saving your import settings to a file next to the collada file you're importing with. When you re-select a previously uploaded collada file, the importer should load those settings. If this is not the case, that's a bug we should fix

These kinds of programs are always interesting and can be very handy tools! I'd be excited to hear if anyone has any first-hand experience with them and can report back on what kind of results they generate. My guess is that it probably creates a pretty high-detail mesh, that would need a non-trivial amount of cleanup to make it suitable for upload to SL. The reason for this is that automated tools like this don't know what details are important to the overall look of the object, which details can be covered by texture detail, and whidh details can simply be optimized out. It would also be interesting to see how such tools generate their textures and UV maps, and if optimization is needed there as well. Its a similar problem to the reason why automated tools to generate levels of detail are going to continue to be less quality than if you generate your levels of detail by hand. Automated algorithms can use some statistics to make semi-intelligent decisions as to what details can be removed while causing the lowest impact on the overall shape, but an artist will be able to know which details are less visually important and can be greatly simplified, while others are more important and should lose detail less quickly. Definitely interested to see some results and hear back as to the suitability for import! -Nyx

Joint displacement works now. Joint rotation and scaling will be implemented in the future. Extending the base skeleton and/or supporting custom skeletons is also a featureset that is desired but is not practical to be included in the first release. Non-skeletal morphs (such as expressions, mouth movement, etc) will not affect rigged meshes.

Apologies, I thought the inquiry was about the UV maps of the avatars that were linked on that page. To clarify, could you point to the exact files detailing the avatar mesh & armature that you'd like license clarification on? Thanks! -Nyx

The bulk of our documentation time is going to be spent focusing on the import process after a collada file has been generated from your software package of choice. There's pletny to be documented in the import pipeline, upload process (wizard and advanced), primitive cost calculations, etc. We probably won't have the cycles to do a complete walkthrough of how to export a mesh from every major 3D editing package before release, though it may be helpful to set up the structure of the pages to allow for user-generated guides for this. Walking through how to export a mesh from a collada file should be a guide that many are capable of assisting with. Personally I'm more hopeful to get us to publish guidelines on best practices when designing and importing content optimized for our particular system, as that will benefit all creators, regardless of what tool they use to model in.

please see the latest license file attached to our clothing templates: http://static.secondlife.com/downloads/textures/fashion/All_Fashion_Design_Templates.zip you can access this from: https://wiki.secondlife.com/wiki/Clothing_Tutorials If there is still licensing ambiguity, please respond on thsi thread - I'll be keeping an eye on it. I was under the impression that our latest licensing terms clarified the issue for most people. -Nyx

We're re-working the upload pipeline. The desired behavior is that textures referenced in the collada file will be uploaded with the geometry and included in the upload fee calculation. This work is not released yet however. Please retest once we've deployed the viewer & server combination for the new asset format (coming soon!). If it still reproduces after that release, please let us know ASAP as it is a bug we will want to fix. If you'd like to send in a sample collada file in advance, I can make sure our devs have acces to it to test the new pipeline. -Nyx

Internal to the code, its also sometimes referred to as a "TextureEntry" as that's how its stored - a texture and its associated properties,etc. Some 3D modelers refer to this concept as a "Material Group", as that term does not imply anything about the connectivity of the various pieces. It certainly won't be possible to eliminate "face" from the common lexicon as its baked pretty thoroughly into LSL (then again there its conflated with the term "side"), but it could be possible to update the terminology in the UI and documentation if there is a significant benefit in clarity. I'll make sure our UI designer takes a look at this thread. Thanks! -Nyx

As Drongle indicated, as long as each individual mesh "prim" does not exceed 64m on a side, it should be fine, even if the sum of the pieces is greater than 64m.