Jump to content

Oz Linden

Lindens
  • Content Count

    241
  • Joined

  • Days Won

    1

Everything posted by Oz Linden

  1. Debugging issues with the CDN isn't very easy, but it's impossible if we don't get very careful and thorough reporting. For example, including where you are, how you are connected to the network (who is your ISP), exactly what sort of problem you had loading (images, inventory, mesh objects, whatever), what region you were on, what time it was (including the timezone or explicitly in SLT). We have occasionally been able to diagnose and correct problems when we had enough information to go on....
  2. Whenever you're asking about a Viewer problem, it's helpful if you include at least the viewer version information from About Second Life (even better is all of what's in that box... we even have a handy button for copying it). As a part of the 64 bit viewer project, we're revamping how upgrades are downloaded and installed in an attempt to make them more robust and quicker (and incidentally to make sure that Windows users get the 64 or 32 bit version that will work best on their system). That component isn't in the Project Viewer yet, but we are integrating it now so it will be in an update soon.
  3. Have you tried the VLC viewer for your file? It uses much newer media handling. You can download it from http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers There will be an update to that viewer posted this evening, but the current version should work.
  4. Of course we read the forum ... we're just quiet and retiring by nature
  5. Solving that problem would require major rewrites to lots of viewer code; it is not on our roadmap at present.
  6. Just FYI ... there's nothing magical about 80,000; that's the default for Medium graphics setting (and most Macs). The default you get will vary depending on the viewers assessment of your GPU - high end ones will default higher, and some may default lower. It's a great goal, though. I have my own viewer set to around 100K most of the time, which really improves performance by cutting off the very expensive ones.
  7. This is fixed in the current default viewer, and that fix will be in the next Bento Project Viewer update
  8. Also see http://wiki.secondlife.com/wiki/Avatar_Rendering_Complexity
  9. Also see http://wiki.secondlife.com/wiki/Avatar_Rendering_Complexity
  10. Christin73 wrote: After an update to the viewer lastnight i noticed everything I put on ups my "visual complexity". First off what is visual complexity? Is there any way to turn that off from popping up everytimg you put clothing on or tp someplace? If you look at that message, you'll notice that the words "visual complexity" are a link... if you click on it, it will take you to a page that explains what it it is and why you should care about it. There is a debug setting that controls how long that message is displayed; at the next update, you'll be able to set that to zero to supress them entirely (but you shouldn't).
  11. Webroot has, alas, been implicated in a bunch of problems. If at all possible, find another security package.
  12. Can we please try to keep this thread focused on the Bento features and bugs without getting into a discussion of the relative merits of different modeling and animating tools?
  13. Gael Streeter wrote: This is a very very old known bug : When importing a BVH animation into SL, the SL viewer performs an "optimization" of the animation (to reduce its load). But this "optimization" algorythm has bugs and induces very big problems of "phantom moves" (I call it like that) when the animation has very small moves between keyframes : the fine moves are replaced by big and long incoherent moves. We are trying to find and if possible fix any bugs related to the Bento features. If you can find a good quality report (meaning one with usable instructions to reproduce it), please add a pointer here; if not, please try to create one. Extra points for including an animation file that demonstrates the problem. It may also be that we should implement checks in the viewer to alert the author that an animation does not use an appropriate frame rate, but let's see some actual examples before we draw any conclusions.
  14. Yes, communication is important. Please don't take our recent quiet as an attempt to avoid communication... it wasn't: we were just on holiday. We're looking at having a series of open meetings for and with content creators, and will be posting both those and other things here in the coming days and weeks. Almost nothing is set in stone yet (the bones that existed before Bento being the most conspicuous exception). Second Life Examples Please!
  15. Kitsune Shan wrote: ... Ok now think on that issue translated to the new bones. Take into account that bones have increased to, how much? 3 or 4 times the old ones? Add to that some bones chains for the supossed facial animations. Just the face bones should be increased by 3. Now, with all that try to make an animation. You will then hit a big wall when your animations looks nothing like the ones tried to make, when your face starts to get some muscle spasms here and there and when the file size limits your animations to very short clips. Adding bones chains wouldnt just decrease performance, it would decrease animations quality. Unless these animations file size gets increased by the same amount of bones number ... Leaving the bones translations subject, I would like to recall on the bone per vertex limit issue. We already strugle at time to rig using fitted mesh bones in combination with default ones. Certain parts are surrounded by more than 5 bones while the limit is 4. This gives you distortions on skinned meshes and often puts you on the choice of having to disccard some necessary bones simply because you cant add more than 4. If the limit is really tight already, try to imagine if you add the new bento bones. Think when you will try to make a smooth facial skinning but you cant use more than 4 bones per group so you have to discard essential facial bones for an optimal animation. We need a limit of a minimum of 6 bones per vertex. I am not programmer so I am not sure wether tis can get scaled to 6 or if have to be directly raised to 8 like most games engines. But the fact is that we really need to be able to rig to more bones per vertex if we want to use the new bones, fitted and old ones properly. Without commenting on the merits of either of those issues above (because I don't have an opinion yet), I'd just like to point out that they would be perfect for filing a Jira issue including rigs and animations that clearly demonstrate the problems... doing so would be far far more effective than the post above alone.
  16. Working for me... When reporting a potential system problem, it helps a lot to be specific about exactly what is happening.
  17. A couple of quick items… Linden Lab employees have a holiday from December 24 through January 3 this year (what can I say - it's a great company to work for), and some have added a bit on one end or the other of that with vacation days. Some of us will be monitoring this thread during that time, but we probably won't do any deep analysis of issues raised until after the holiday. We're not going to rush this feature out - there will be plenty of time for discussion and consideration of each issue. At the risk of repeating myself - please try to make thorough examples that illustrate whatever problems you see. By that, I mean: provide model and animation files that we can examine and experiment with. A screenshot or a video is fine along with those, but by themselves they are really not very useful. Along with those files, provide careful descriptions of what you think should have happened and how that differs from what you see actually happening. Try not to assume that we know anything; avoid references to "the SOMETHING bug": we may not have the same idea you do of what SOMETHING you mean). Make sure that you do all testing on the Project viewer (you'll get updates automatically when we get back to making new versions) and one of the Aditi Mesh Sandbox regions. I've seen a number of posts here that include some variation on "we have always had to do XYZ this way because of the SOMETHING bug, and so we can't do SO-AND-SO" (for example, joint offsets not loading correctly). If there are existing issues that are directly related to Bento (like joint offsets not loading correctly), we'd like to get them fixed so that we can get some of these obstacles out of the way. So, if you've got one, please describe it (see previous paragraph - concrete examples we can experiment with) by filing a BUG in Jira (put [bento] in the Summary). References to long-standing issues are ok; we're not only trying to do new things, we're trying fix at least some old ones too.
  18. ObviousAltIsObvious wrote: if you miss the feature and don't want to wait, you can change the --channel name (for example in a shortcut) to bypass updates for now. Actually, if you just download and install the Quick Graphics Release Candidate from the Alternate Viewers page you'll get the feature back. Users on a release candidate are not updated automatically to new default viewers. It was explicitly downloading the new default viewer that caused the OP to lose the feature. There will be an update to the Quick Graphics candidate soon after the New Year to pick up the 4.0 features (we are not making any non-emergency changes during the holiday period so that Lindens can relax and enjoy the holidays). If you're running the current version, that update will be automatic (and mandatory).
  19. Medhue Simoni wrote: The development side is the 1 I really do not get. What was the point of making this a CLOSED beta? Why did you make people sign NDAs for this? Why would you threaten people with legal action for talking, over adding bones to an avatar? First and most important, we did involve quite a few resident creators in this project from very early on - we could not have done what we have without them, and we very much appreciate their generous help. What has happened to date was not a closed beta, it was the initial implementation - what we just started yesterday was the beginning of the beta, and it's wide open to everyone. As Vir has said, we may well make significant changes based on this beta (which is why none of this is on the main grid yet, so that we can make changes that are incompatible with what we have now). As someone here has already suggested, when we begin a project that we consider to have significant risk we prefer not to discuss it externally because we don't want to cause confusion or set inappropriate expectations. We've been working on this for several months - consider what it might have done to avatar and animation sales during that time if there were rampant rumors about how we might break everything, or even just that big improvements were coming. Since we could not be sure either what the final scope of what we could do would be or how long it would take, we didn't want to cause that kind of disruption. It wasn't possible for us to keep the secret (which, suprisingly, we apparently did pretty well) without some limits on how many people we brought in. I'm sure that there are many more creators out there who could have contributed, and we look forward to getting their input now. One small request ... please actually get the Project Viewer and test how things work, and try the tools that are available to work with them (if there are other tools we can help to support these changes, we're ready to help). In the course of this project we've tried to address a number of problems with how rigging and animation work, so you may find that old problems have been improved. We very much want your input on what we've done so far so that we can bring this to all of Second Life.
  20. Now. https://community.secondlife.com/t5/English-Knowledge-Base/Enhanced-Skeleton-Project-Bento/ta-p/2975160 https://wiki.secondlife.com/wiki/Project_Bento_Testing
  21. Ok. We get that you would like demo items excluded from search. We can't do that immediately, but we get it. You can all stop repeating that now, and really we don't need 30 point bold type for anything.
  22. Sorry about that ... most of our Release Candidate viewers prove to be ready to go when we put them out in a test group, but once in a while one needs a serious problem solved. You were unfortunate enough to be caught in one of those. If it's any comfort, your experience prevented others from having the same problem. We've fixed that bug, and are putting the update through QA now - it should appear in a few days for another test (your odds of being picked for that test are not very good). The good news is that while the problem you experienced was serious enough that we withdrew that viewer until we could fix it, our overall results with it were excellent - it had the best crash rate we've seen in years, so with this fix made we're very optimistic about it.
  23. ChinRey wrote: Do you feel the visual complexity algorithm is exact enough to target the high lag avatars precisely enough? And if so, can you explain a little bit why? I don't think I'd use the term "exact" for anything of this kind, because different features have slightly different real costs depending on the capabilities of your system. Short of having a very deep understanding of the specific capabilities and performance characteristics of every graphics system out there (many many thousands), an "exact" formula isn't possible. So the question is "is it good enough to be useful?", and we think the answer to that is "yes". Certainly many of the Lindens who've been using this viewer for months (including myself) have decided that the feature is very very valuable. Personally, I usually run with my limit set to about 100,000 - good enough to display most avatars in the settings where I spend time, and keeps my lag under control even in substantial crowds.
  24. Loraan Fierrens wrote: Out of curiosity, is there any work being done to provide some sort of proxy layer for viewer doing MOAP? Not at this time.
×
×
  • Create New...