Jump to content

Runitai Linden

  • Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About Runitai Linden

  • Rank
    Advanced Member
  1. 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.
  2. 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.
  3. 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.
  4. 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
  5. 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, bu
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. 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 Wh
  11. 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
  12. 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 in
  13. 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
  14. 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 discussio
  15. 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?
  • Create New...