Runitai Linden

I wouldn't recommend selling an .SLM file. The SLM file is not guaranteed to be compatible with future SL versions, so if someone bought the SLM file there's no guarantee they'd be able to use it. We do plan on supporting direct SLM upload, but it's very low priority. There is no creator or uploader information in the SLM, so anyone who uploads from an SLM file will be listed as the creator.

It's a feature -- rigged attachments use the avatar skeleton bounding box when determining LoD. This is because a rigged attachment's non-rigged size as known by the CPU can vary wildly from the rigged size as known by the GPU. Synchronizing between the two takes a lot of cycles, so we just use the avatar skeleton bounding box as a best guess.

Mesh assets are as secure as textures, which is to say they are not secure. Selling a .dae is like selling a Photoshop .psd file, and selling an .slm is like selling a jpeg. If you want the "creator ID" to always be your ID, never sell or share an .slm or .dae file. Mesh is vulnerable to copying just as textures are, which is one of the reasons we require payment information on file to upload a mesh. When you upload a mesh, the simulator embeds your agent ID and the date the mesh was uploaded inside the mesh asset, which makes it much easier to resolve disputes of who uploaded what first.

Two things: 1) We're aware this is an issue, and decided it wasn't a blocker for initial release because: - you can fairly easily hit similar numbers by attaching 8000 sculpted prims. - as you've seen, the viewer just stops rendering triangles on attachments once the attachment gets insanely heavy - if you "mute" someone, you stop rendering their attachments 2) The plan is to make the visual "muting" automatic based on client preferences -- if you wear incredibly laggy content, others will see you as they see muted avatars. Unfortunately, doing the analysis on an avatar to determine if said avatar is laggy actually creates lag (you may have noticed reduced framerates when displaying ARC), so the two main blockers are to a) define "laggy", and b) make determination of "lagginess" not laggy.

We actually kicked this around a bit and settled on "Mesh" because at the core platform level, what you're uploading *is* a mesh. In COLLADA terms, In the importer, each "geometry" node in the scene is turned into a single distinct mesh asset, and each geometry_instance in the visual_scene becomes a Second Life object that references that mesh asset. You get a "face" or "texture entry" for each "material" entry for the "geometry" node in the COLLADA file. You're correct that the importer is dealing with "scenes," and the "Model..." button was in fact labeled "Scene..." early in the beta, but since a "Model" is technically a collection of meshes, it's just as accurate to say "Model" and it's more obvious what the button does. In terms of what you get after import, it's exactly the same scene and object management as the old platform, except the geometry that makes up an individual object is pulled from a mesh asset instead of a set of primitive parameters. Of course, the details of making that work efficiently, securely, and in a way that's scalable are what's kept us busy these past two years, but there it is in a nutshell. So there you go, "mesh" import is what's happening, and we import "scenes" by importing lots of "meshes." Also, we *only* support mesh import, so claiming full compatibility with COLLADA beyond meshes would be incorrect (we don't support nurbs for example).

The import is misleading you -- You need to go to the "modifiers" tab and check "skin weights" and "joint positions" The gears drop down just contains what's rendered in the preview, not what's imported.

Looks like he popped down to a lower LoD. This has been happening to me, too, on occasion, but I didn't notice the correllation with region crossing. Thanks for the heads up, this information should help track down the cause.

We'll suss out a better placeholder graphic in future releases, but since we don't have a time machine and can't inject code into legacy viewers, this is what meshes will look like for anyone who doesn't update their viewer.

Short version: Update to build 236082 or later if you're seeing prims where you used to see meshes.  236082 is building now (2011-7-18 21:12 SLT) and might not be available. Installer links here: Windows -- http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/mesh-development/rev/236082/arch/CYGWIN/index.html Mac -- http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/mesh-development/rev/236082/arch/Darwin/index.html Linux -- http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/mesh-development/rev/236084/arch/Linux/index.html   Long version: In an attempt to make some non-mesh enabled viewers (i.e. viewers based on the 2.7.2-2.7.5 releases) display something meaningful (and not crash) when encountering mesh content, we're testing out a protocol change that is not backwards compatible with old mesh viewers.  A simulator using this protocol has been deployed to the Mesh Experimental channel, so you'll need to update to the latest mesh viewer to view mesh content on the following regions: Mesh City 2 Mesh Sandbox 1, 20, 21, 27, 28, and 32 MeshHQ 3   The new viewer *is* backwards compatible with old sims, so you can use it everywhere, not just on Mesh Experimental sims.  If you're wondering how we pick which prim to show for which mesh, it's based on the number of texture entries in the mesh asset (the prim you see has the same number of texture entries as your mesh).  Your mesh object will also appear as this prim if you take it to a region that is not mesh enabled, and this is the prim that people with any legacy viewer will see in place of your mesh.            

Ann Otoole wrote: Runitai Linden wrote: ... The current budget of 250 thousand was used by examining the triangle count of various inworld locations and looking at performance characteristics and capabilities of target systems (which are slower than you might think). ... What are you "targeting"? Mobile systems? Tablets? iphones? This is a fair question that we definitely haven't answered fully. Here are some statistics I'd like to share: As you may know, the viewer categorizes machines into 4 classes defined here: http://wiki.secondlife.com/wiki/GPU_and_Feature_Tables#GPU_Class What you probably don't know is what percentage of residents (your customers) fall into each class: Class 0 - 34.86 % Class 1 - 17.08% Class 2 - 14.25% Class 3 - 26.95% The ramaining 6.87% fall into an "unknown" or "unsupported" category. To give you an idea of what qualifies as "Class 0", as of the last report, these were the top 10 chips in that class: 1. Intel Bear Lake 2. Nvidia GeForce 6100 3. Intel 965 4. Intel 945G 5. NVIDIA PCI 6. Intel 945GM 7. ATI Mobility Radeon 8. ATI Radeon X1xxx 9. Intel Cantiga 10. NVIDIA GeForce 7000 We're basically talking about $400 laptops, so that's the target. If you've got a beefier machine, keeping the scene lean will let you crank up your mesh detail so you never see those ugly low LoDs, push your draw distance out, and turn on effects like shadows and water reflections.

Drongle McMahon wrote: *the present max_area effectively sets the draw distance of the low-end user, who the limit is designed for, to 181m, when the medium graphics setting that is supposed to be the target, is 96m. The effect of this inconsistency is about a doubling of PE, and disproportionate increase in PE for larger meshes, but I don't think that is it's intention. I think it is just a mistake. You keep bringing this up, but look at how the math works out and you'll see that the larger the max_area is the lower the streaming cost is, because the streaming is based on the average number of bytes visible over max_area. Effectivelly, the average number of triangles visible over max_area approaches the number of triangles in the lowest LoD as max_area approaches infinity.

The streaming cost component of PE is based on the average number of bytes visible within the area of a circle that circumscribes a region. Larger objects LoD sooner, increasing the average number of bytes visible over that area, making them use more bandwidth. While it's true the actual displayed LoD is dependent on user settings, the streaming cost calculation is based on a constant LoD ratio and is therefore viewer setting independent. The target triangle budget is 250 thousand triangles visible from the center of a maxed out region, but you can increase that budget for your viewer by increasing your detail settings in preferences or increasing your draw distance. The current budget of 250 thousand was used by examining the triangle count of various inworld locations and looking at performance characteristics and capabilities of target systems (which are slower than you might think). The budget is also biased a bit low for initial release because it will be easier to raise the limit later than lower it.

Failed Inventor wrote: They say don't compare meshes cost to prim cost, well honestly follow your own words LL. Forget prims give parcels a triangle/vert limit, and same with avatars to. Why? *Waits for the linden fan boys with their torches and pitchforks to burn me at the stake for expressing non prolinden views. That's exactly what the "streaming cost" PE does, it just presents the number in terms of "prims" because that's what the existing accounting system is setup to handle. It does exactly what you're talking about, it just converts the number to the same units the system is used to dealing with.

Ok, getting this very helpful, insightful thread back on the rails -- Two quick things and one long thing: 1) We were using diameter instead of radius, fixing that now, and the error margin seems to be getting smaller because of it -- thank you. 2) The new total area of 102k is the area of the circle that circumscribes a single region -- I found that using the area of the region (65536) tended to give the lowest LoD less weight when determining the average and resulted in a higher than accurate streaming cost. The long thing: realistic budgets I'm absolutely thrilled that the discussion is turning towards triangle budget and framerate analysis instead of comparison with individual prims, but there seems to be some misunderstanding of what "scene statistics" reports. The "Render Info" display describes the currently rendered frame and includes information about everything in your current view. The "Scene Statistics" console describes everything in the region you're currently in that the viewer is aware of, so it could be missing small object that are far away, and it definitely excludes content from neighboring regions. What this means is the triangle budget of 250K is for a single region at medium mesh detail settings. If you have a machine that can handle more than that, you can spend the extra power bumping up your detail settings, pushing out your draw distance, and enabling effects that require multiple render passes (like shadows and water reflections). Someone asked for a report on graphics hardware. I'll see what I can dig up.

Drongle McMahon wrote: I have wondered about the W before, but have no real idea what it does. I did read something about it being used in transformations to give the texture a perspective transformation. I would guess it is ignored, but I really don't know. Runitai, are you there? Help! It is ignored -- actually, I think if it shows up in the .dae file, UVs won't parse with our importer. Anybody got a .dae with 3D texture coordinates to test?