Nyx Linden

We've done a handful of smaller tests of SSA. The roll tomorrow will be to a full RC channel, as previous testing has not turned up release-blocking issues. We will be monitoring the release carefully. If you note particular oddities or bugs with the release, please file a JIRA with your observations and we will investigate.

Getting back on topic.... The short answer is that non-compliant viewers still show meshes as meshes are just special types of prims. They show up as prims because we couldn't go back and add code to all non-compliant viewers to tell them to not render meshes. We added code server-side so that non-compliant viewers would see a prim with the correct number of textures on it. Whatever interface style you prefer, many viewers are adding mesh support. Hopefully the majority of users will be able to see meshes soon!

z offset is specified as a static value on upload. If you resize the avatar from the state when it was updated, then the z-offset will be incorrect. There is not an "easy" way to determine programatically exactly how much the z-offset needs to be scaled or modified if you resize the avatar. There are some ways to do it based on the avatar's skeleton, which is how the offset is computed for non-rigged avatars, but having a manually specified z-offset is the creator telling the system "ignore what you know about the size of this avatar, the pelvis should be this far off the ground". It would be nice to provide a mechanism for the creator to specify how that value should change as the avatar gets modified, or to figure out a way to reliably calculate what the new value should be, but its not a huge priority for us immediately.

When an object is made "physical" / dynamic, it creates a heavier load on the servers than non-physical/dynamic meshes. So you can expect that the physics weight of an object will go up when you make it physical. If the object is at or below 32 prims of physics weight *before* you make it physical, you should be able to successfully make the object physical. This will raise its physics weight (often above 32), but that is acceptable, as long as its physics weight is below 32 before you check the "physical" checkbox. As for the specific example listed here, is it rezzed anywhere in particular, so that we can take a look at it and see if the numbers being reported are accurate? We're always looking out for assets who's costs seem unreasonable, to see if we need to adjust our algorithms. Thanks! -Nyx

All the normal controls you have for editing prims and sculpties work for meshes as well (retexturing, coloring, changing scale, copying, adding scripts, editing permissions, etc). The only options you don't have are those that edit the shape of the object itself, as that is determined at upload time. Other than that meshes are just like any other primitive.

We're asking for testing on specific builds of that branch, we think we have a fix for the reported issue, so please try the following viewer: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/vir-project-1/rev/237585/index.html

please try this viewer, we think we have a fix for this issue: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/vir-project-1/rev/237585/index.html Thanks! -Nyx

Yes, the fix for active UI elements being glowy/white/washed out should be merging into viewer-development soon before or after the mesh code, so that isn't much of a concern. We're trying to hunt down the upload fee response hang, stay tuned!

We've noticed this on one machine, but are having difficulty reproducing broadly. What exact viewer version are you using? Could you get the contents of the about secondlife panel and a secondlife.log file to us either by JIRA or email? Thanks! -Nyx

Unfortunately its not just a web browser incompatibility, there's a bug in some code in our internal tools. We know what the issue is and are working on fixing it. It should only affect a handful of people though, if you know of anyone else having trouble, send them our way!

Full permissions in Second Life implies that you have the right to modify/copy/transfer the object within Second Life. Full permissions does not imply that you are allowed to export the content outside of Second Life.

We have declined to implement direct editing of meshes, textures, sculpties, animations, sounds, or music into the viewer for a number of reasons. Part of the issue is the way our asset storage works. The larger issue, however, is that the viewer and its functions are already very complex. And editors for each of these assets are equally complex, especially the ones that provide a lot of powerful options to create high quality content. 3D modelers in particular tend to involve large teams working for years to create a powerful product with sufficient functionality to do serious 3D modeling. We have basic primitive-based modelling in the viewer today, but anything more complicated than that would take a huge development effort to either implement our own, or integrate an opensource package. It would cause our viewer and its interface to get massively more complex, would be very difficult to maintain properly and keep up to date. And for each of these functions, there is a range of freely available professional-grade tools for creating each of these types of assets. In short, we have plenty of other things we need to focus on! Thanks for the suggestion though! -Nyx

Greetings all!    As we're preparing to make mesh a feature available in our default viewer install, we've created a mesh viewer that is being used to test how well the mesh functionality works in the latest codebase. It doesn't have 100% of the latest and greatest fixes, but we believe it should be a stable viewer for your everyday use. If you have some time, please install the viewer linked here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/vir-project-1/rev/237585/index.html  And give us your feedback! Make sure to test mesh uploads, as well as the functions you commonly use in your regular viewers. If you have any issues or notice any bugs, please file a JIRA bug report and list the issue number in this thread. Thanks for your assistance!    -Nyx   [edit] updated build link to have fixes to reported issues. thanks for the feedback!

Agreed, but the majority of users won't need to specifically see the physics weight, and presenting all five numbers (objects, prims, prim equivs, physics, and render) is too overwhelming to present to every user in that view. Its required for vehicle builders to see the physics weight, so we have a debug setting for that for now, but we're looking into ways of showing this number (and more) that is easier to find for those who want to see the extra detail. In short, we're working on it

complex physical models that aren't decomposed will get more expensive the smaller they are, because it has a higher triangle density. You can probably make your mesh *much* cheaper by using a more efficient physics representation and then decomposing it.

the mesh-enabled code will eventually reach all beta grid regions, at which point you will be able to test your uploads from any region on aditi. So you will always be able to use the beta grid to test your object uploads! As to whether the current meshy regions themselves will stick around, that's harder to say, but I don't believe we currently have plans to remove them. That may change in the future, but not before the rest of the beta grid regions support mesh. -Nyx

We had to disable that, as the direct tie from your avatar to the avatar in the floater was causing some persistent in-world issues. Sorry -Nyx

As stated above, adding support for custom normal maps is something we'd like to look at in the future, but we don't have the time for before the first release of mesh. Stay tuned!

Noted! Hope to have a patch for this later today. -Nyx

Nice to have, definitely don't have time to do this for initial launch. Catching operations that would cause overflows in advance is definitely something we've looked into but it would take significant resources that we just don't have before the initial release of mesh. -Nyx

indeed. we should be able to remove this. -Nyx

Verified its filed correctly and will be worked on.

I'm going to be reviewing the algorithms for computing these costs over the next couple weeks. A twisted torus has a lot of concavities, and a high triangle density. The fact that it costs more to compute in the physics engine is a fact of how complex it is to compute things physically. The higher the triangle density and the more concavities an object has, the more calculations need to take place when it collides with something. A box on the other hand is exceedingly simple to calculate a collision point for. That's not a bug in the physics engine. Whether it is really 13,000 times more expensive is something we'll be investigating to see if the algorithms are accurate or need more tweaking for the more extreme cases. With this system we're trying to be more honest and up front about where our systems experience load that can cause lag. This is information we've hidden from and abstracted behind the primitive model of limiting things (if a simple prim costs the same as a very very complex prim, our accounting model doesn't map to our resource usage well). Of course we can't change the old accounting model for legacy content without risking breaking a lot of content, but that doesn't mean that we need to continue a poor model of accounting for new things like mesh.

When regular prims have the physics shape type "prim", twisted toruses really are that much more complex to the physics engine. We've just hidden that complexity in the past, which creates some interesting load challenges for our physics system. We're still in the process of reviewing the formulas, but in the meantime, could you try setting the linked torus' shape type to convex hull and report back on how that affects the numbers?

Interesting thing is, it *is* actually that much more complex to our physics engine. We do full simulation of a shape very close to the render shape for regular prims, and in the case of sufficiently convoluted torii, its a bit of an issue to say the least. Could you try setting the torus' physics shape type to convex hull and see what effect that has on the reported cost? Any suggestions on how to clarify how the new system works and/or how to get the word out to inform builders before they run into the "gotchas" would be greatly appreciated