Jump to content

Charlar Linden

Retired Linden
  • Content Count

  • Joined

  • Last visited

Everything posted by Charlar Linden

  1. ohhh whoops! I said Kwak, but meant Chosen. You're both so damn helpful, I get you confused. That's my story. Charlar The Terribly Confused
  2. Siddean, I think Runitai may have marked it dup because the core graphics problem was the same - but I'm not sure to be honest. I'll try to check on this and the related items, but please do check the latest shining dev build and let me know Charlar
  3. Thanks lifedancer for the suggestions. It's great that you're exploring and learning. I think the responses you got from folks here should be helpful to you, and also should give you some context to the constraints of the world. As you've seen, the vast majority of residents are helpful and welcoming. Remember that when you inevitably run into a troll - just move on and it'll be fine. :-) I feel it's very important for residents to find that building in-world is both intuitive and engaging. Right now I think it can be very engaging, but it's not intuitive. Visit the locations Penny mentioned; it's truly amazing what has been accomplished with prims and the existing build tools. At the same time i want to give those residents that want it the freedom to make much more complex builds; mesh import is the primary pipeline for that need. One note - Kwak, I think what lifedancer meant about defining linksets is more this: Define the linkset object first, say "My House", give it a description. Then select objects - Perhaps there's a menu which lists nearby valid linksets to join the object(s) to. You could choose the base object for collision as well. That's what I read, anyway. I can see advantages to that workflow which treats the linkset as a real and separate thing, vs. the current one where it's more implicit and only exists as a result of it's children. I won't comment on whether we'd do something iike that. If we were to reconsider how you interact with linksets it'd be as a part of a larger redesign of the build/edit floater and workflows. If I got that wrong, please let me know. Charlar
  4. https://secondlife.aditi.lindenlab.com/my/account/mesh-landing.php? This is the link to the aditi mesh tutorial. If you're having a problem, please try this and tell me if you get a different result. Charlar ps: please tell me if it all starts working too, that way I won't sit up and worry about you. ;-)
  5. That is a very nice purse. I won't participate, but I've written the answer down and will be watching. I do like the answer "476". If Madeliefste was new to this, I think that might be close. Charlar
  6. Zarniwoop, Davido - could you tell me exactly what that link does when you click it? I'm looking into this. Charlar
  7. You could reopen the previous one, that'd be fine as well. The thing is, I haven't seen it - if you enter the JIRA you can give much more useful detail and when we assign someone to look at it, they can contact you if needed for more information. It may seem beauracratic but it's a needed bit of workflow for us so we can prioritize, get someone to work on it, and make sure it's tested. It's also needed to communicate with you and anyone else who 'watches' it. Charlar
  8. Meeting Notes: https://wiki.secondlife.com/wiki/Mesh/Archive/2012-01-23 For next week, please add items here: https://wiki.secondlife.com/wiki/Content_Creation/Mesh_Import_User_Group thanks everyone for attending and taking an active part. Charlar
  9. Good point. I think it's certainly possible. Just need to find a little time, and a JIRA... Charlar
  10. Awesome - thanks! It's very generous of you to let everyone see some of the inner workings of a mesh build. I'll come visit tomorrow Charlar
  11. Yes, there are certainly some helpful and knowledgable people here. To generalize one aspect that is important for anyone building with mesh objects: LI is the end result, but the resource weights are what you should be watching as you build and experiment. Mesh is more flexible and allows significantly more control than previous building formats (prim and sculpt), but it's also more complex. Prim building is much more straightforward, but there will be things you can simply never do. We show the resource weights of objects in the uploader, so you can see what they will be like before uploading (minus the effects of scale). This can help you get a feeling for the effects of LoD, but also tells you if something that is not your focus, like Physics, for instance, is high and driving the LI. I realize our doc on the wiki is not as helpful as it should be and I'm trying to find the time to improve it. Charlar
  12. Great thread folks. After explaining the basics of physics, you went on to cover LoD practice really well. I've tried to explain each several times to people (with varying success) and I believe they're critical for mesh optimization (LI and visual). You gain flexibilitiy and power by understanding how it works and what your options are as a creator. While this was generally focused on large objects, I think the concepts can be applied to make smaller objects even more efficient. The key is to think about how far away a given object should be visible. Sculpt furniture (in particular) drives me crazy because it usually breaks down too quickly even in a room of 'normal' size. I love seeing these new amazing structures, send me slurls or ping me in-world - and let me know if I can post a picture of it or if it's sekrit. Charlar
  13. If you look at the resource weights in the uploader, you'll see which one drives the LI (Hint: it's the highest one). There's also a checkbox under the preview window that will show you the collision box. You can begin to see why one is more expensive than another. As Medhue said, it's almost always better to make your own, either in your modeling tool and loading the file in the uploader, or building a collision shape out of simple prims in a linkset. You will have much more control over the shape, and can optimize the cost for your needs as well. Charlar
  14. Tepic, the forum is a great place to confirm if a problem is real, and get help, but if you feel this really is a bug, can you enter a jira so we can get this triaged and researched? Charlar
  15. Because of the US holiday, we weren't able to have the content creation usergroup. I had planned to give you all some information on mesh related stats there, so I'll just do it here instead.   Mesh adoption on the grid continues a steady rise, hitting 25% of the grid today. This means that a quarter of all regions on the grid contain at least one rezzed mesh object (not counting avatars, obviously). More than 2/3 of residents are using mesh enabled viewers; this trend is also on a steady upward trend. Session data mirrors this trend. Regarding the uploading of mesh objects, we have a steady upward trend in both volume and unique uploaders for the past couple months. See you all at the UG next week, or in-world between then and now. Charlar
  16. To make sure I'm helping you with the right problem, please give me specifics. What are you trying to do? If you're seeing an error/warning message, what does it say? What grid and region are you on? thanks Charlar
  17. Meeting Notes: https://wiki.secondlife.com/wiki/Mesh/Archive/2011-01-09 Agenda: https://wiki.secondlife.com/wiki/Content_Creation/Mesh_Import_User_Group thanks everyone, see you next week Charlar
  18. LOL, Kwak. Thanks. As soon as I figure out HOW to change it, I will. Charlar
  19. Thanks Drongle. QA will take a look and then we can see how we'll need to handle it. Charlar
  20. We will be introducing a change to make our rendering consistent between non-deferred and deferred rendering settings. Prior to this correction objects set to Shiny looked very different between the two modes. We realize that some of you have done work with the current deferred rendering behavior in mind; please get the beta release of the Viewer so you can see what the change will bring and can make adjustments. The 3.2.5 beta viewer is available at the bottom of http://secondlife.com/support/downloads/ If you're uncertain what this refers to, you can review the JIRA here: https://jira.secondlife.com/browse/SH-1912. Please ask any questions here, not on the JIRA since it's Passed QA and we won't be monitoring it closely. Related to this, we are currently collecting information on your interests for a Material System solution project. Please review the thread http://community.secondlife.com/t5/Mesh/Materials-Project-Wishlist/td-p/1057107 and add feedback for what you would like to see in a Materials solution. Charlar
  21. Exactly Siddean. It's about efficiency, and in the case of avatars, it's all about giving residents the knowledge to understand why performance is different in different circumstances. You might have a super-powerful rig, but the other people in the room may not and when their FPS suddenly slows to a crawl, it's helpful to everyone that they know why. We don't want to limit anything because there are plenty of circumstances where a high cost avatar is desired (photography, machinima, groups where everyone has good rigs). Rigged mesh seems to me like a really great step forward for furries, as much as for any other avatar type. We're excited about improving support for all types of avatars; human, furry, mech, tiny, etc. To add context to the discussion about adding a second class of avatar, one that takes advantage of the advances in the tech: Yes, we could, but doing so is similar in many respects to our addition of mesh support. There's a bunch of code to add it at all, but then there's also a host of ancillary issues (do old anims work on new avs; can new avs sit on old chairs? What about the reverse? Clothing support? etc. etc.), and social issues (e.g. if features are made for new avs that aren't backward compatible, does that mean old avs become second class citizens?). Solving each one adds more work, or creates compromises. That's a long winded way of saying "it would require significant resources and work to do correctly", and we have to balance any undertaking against other priorities, which is something we're constantly doing. The forums are a great place for us to get a feel for overall resident interest, so please keep talking (not like I have to encourage that with you all). Charlar
  22. Baloo - Exactly! The number is simply a reflection of the relative difficulty of rendering the avatar. If you have a good card, those high numbers are much easier, if you have a 'less' good card, there is more likely going to be problems; usually showing as lower than expected FPS, feelings of lag and or sadness. Inefficient use of sculpties, high levels of detail for no reason (prim shoelaces are a classic example), and non-decimated meshes can all contribute to unhappiness among your fellow avatars. The number imposes no hard limit, it's merely a way to help residents better understand why things aren't running the way they expect. For example, a Linden found a coat with fur trim (prim/sculpty/flexi) that tipped the scales at 320,000 points, all by itself. This coat can choke everyone else in the room, but it could be made far less inefficient and we hope that this information will help creators do just that. Charlar
  23. as Kwalkkede said, if your cost feels too high, then you probably have an unoptimized model. If it's unoptimized, then it'll have an inappropriately high Land Impact, and then you'll be sad. No one wants you to be sad. If you'd like additional feedback from other content creators, please post what the resource costs are from the upload window, as well as a shot of what the object looks like. Additionally, while you are testing an object, and especially when you are actually new to uploading, we suggest that you use Aditi for for your uploads. See: http://wiki.secondlife.com/wiki/Mesh/Basics (the highlighted part "Save L$ by testing on the beta grid") Charlar
  24. Nal, Definitely agree that saying "we don't talk about there here" is not ideal, but having duplication of topics is also problematic; we should try to be as clear as possible as to the range of topics and help people find where they can mostly likely get information. Obviously, having a single 1 hour UG that covers everything related to content creation is impractical, and lining them all up one after another would make for a long day for participants. I think scripting questions of any complexity really should be redirected to the scripting UG (http://wiki.secondlife.com/wiki/Content_Creation/Scripting_User_Group) or Sim UG (http://wiki.secondlife.com/wiki/Server/Sim/Scripting_User_Group). We can try to answer straightforward ones in the CCUG (content creation user group), but we may not have the right people people present; by 'right people' I am including the scripting greybeards that regularly attend those UGs. Regarding general viewer items, I'm talking with the team about how to handle that. As for Realms, we won't have a UG for that project. We are taking what we've learned and will be addressing individual functionality in the the scripting and/or CCUG. Right now the answer will be 'no comment' on most of it because we're not ready -yet- to talk about the prototypes. Happy New Year Charlar
  25. Archive: https://wiki.secondlife.com/wiki/Mesh/Archive/2011-12-19 Agenda: https://wiki.secondlife.com/wiki/Content_Creation/Mesh_Import_User_Group Next meeting is Jan 9. (LL is closed the next two Mondays) Charlar
  • Create New...