Darien Caldwell

And that's precisely the problem, is you providing ncomplete, vague, mis., dis., and convoluted information that the server does something it does not do. The information in Torley's video is accurate, and works. Period.

If it were not handling graphical information then there would be no need to measure it in FPS. And yet, nowhere in all of that does it say it's pre-rendering any graphics. So Zi Ree is correct. Sim FPS has absolutely no affect on Viewer FPS.

I would like to point out to all the people saying this will increase their bill, that this is false. The bill you get is based on bandwidth used, or in simpler terms, how much data you transferred. The Bandwidth setting in the viewer sets how much data per second is transferred. If you have to download 1000 textures, you have to download 1000 textures, regardless of the speed, and the amount of data transferred remains the same. They are named the same, but are different things altogether. Bandwidth slider = speed. Billable Bandwidth = volume of data. Your bill will be the same, no matter how high or low you set the bandwidth slider, as it affects transfer rate, not transfer volume. The viewer bandwidth setting just throttles how fast the data transfers, in effect how long it will take to transfer these 1000 textures. It doesn't somehow make these 1000 textures equal more data, which is what you are billed for. The only possible factor that could affect your bill is that you can now do *more* in the same amount of time, as you're not standing around waiting for textures to load.

I've been doing this for years, and heavily endorse doing this. It will absolutely change your experience for the better.

It's always fascinated me how different people can look at the same thing but see it differently. Certainly the numbers don't say SL is closing tomorrow. But considering LL only chooses to publish the best numbers, even the ones they published show a decline from last year. Except for the web sales. Now, if only we had the inworld sales figure to match that one. Sometimes it's important to look at what they don't say, and this is one of those times.

<obligatory meh> It works.

I've had a Scripted tool to do this I've used for a couple years. I have to say it's very nice to have the functionality built into the viewer now. I'll have to play around with it some more, the scripted tool can operate on cut faces, not sure if this does.

Having your draw distance at 500 is ridiculously excessive. There's no need to know what's going on 3 sims away. Try 128, or better yet 64.

I'd vote for Kirsten's Viewer. It's what I use. http://www.kirstensviewer.com/

I have been using a third party flavor of 2.2 recently, and I have to say I like where it's going. Great work. It's good to see the Snowstorm Team pushing forward with improving the issues closest to the hearts of the residents, and embracing some of the more ingenious 3rd party mods. Keep it up.

Yoki Enoch wrote: Lizard Howl wrote: Yes, it is possible to profit at the $125 tier rate in spite of what other people might say. Really? Well, perhaps you can elaborate on this since one would have to compete with so many Homesteads with a monthly tier of $95.00 per month. I would be very interested in hearing how it can be done - seriously. Make your rent high enough to make a profit. Give outstanding customer service. Make your sims beautiful, and not a boring pancake. People will gladly pay more for this.

Thanks for your comments on the JIRA. Now if only we could get some vote for it. You know LL doesn't implement things without thousands of votes behind it.

Unfortunately the code you wrote won't always work, as the auto-play parameter can be overridden in the user settings. The problem is this setting is global, while more likley people would prefer to selectively have some items auto-play, and others (or most) not. There is no way for a developer to be sure people don't have auto-play off, and that their interface, data is viewable by the people who want to see it. My proposal makes auto-play a per-object setting in essense.

My point still stands - we really have not seen it exploited because few want to subject themselves to the 2.x viewer. I'm afraid that's not he only reason. The other major reason is how it was implemented. Because of the way LL designed MOAP to 'turn off' under so many conditions, it can't be considered a reliable user interface. It serves nobody to be 'off' and unviewable in 70% of the cases it's encountered. And the fact it's not persistent, makes it very inconvenient to use for customers/residents. I posted a proposal to correct some of these issues in the JIRA: https://jira.secondlife.com/browse/VWR-20428 as I would like to see MOAP be all it could be.

I have to say the general consensus from users I've talked to, is that lag is worse. Specifically in the realm of inventory loading, lost inventory due to lag, and issues related to this. So while you may have fixed one small cause of lag (avatars teleporting into the sim), I wouldn't unfurl the "Mission Accomplished" banner just yet. As for the group chat fix forthcoming, is that going to have any positive impact on open chat performance? Many of the same issues are seen with open chat (long chat delays, out of order chat, chat never arriving, etc) I hope these fixes will also address open chat failures as well.

Did you actually read the comments? Only one referred to the economy that I saw and Jack responded to it. Everyone else is just sharing about mesh or expressing frustration that things don't work. I'm just not seeing the mass hysteria you are suggesting is happening. I think his name explains all. That anyone would even suggest there should be cost associated with anything is hysteria, as if he had his way, there would be no costs at all, with anarchy and consequences be damned. You know, the Open Source way. Shame on me for being the adult here and wanting to tackle the hard questions associated with Mesh, which is preserving a balance of cost/benefit for consumers/creators, so SL still has a reason to be. I'm sure LL as a company wants to preserve that too.

Thanks. We definitely need to get some clarification about what these various cost numbers stand for. I know the one on the left is the rendering cost. But the 4 different values on the right, bear some explaination.

Looks nice. How many prims is it counting as? Not parts, but actual prim count on the parcel.

I understand. It's just my opinion that this detail should have been ironed out earlier rather than later. Mesh will work, there's no doubts about that. But more attention should be paid to the implications of it's introduction. For those who are interested in examining LL's proposed cost formula closer, I have created a command-line tool to try the formula out under different conditions. Link can be found on the Talk page in the Wiki for the Streaming Cost formula. I know I for one will be giving it a hard look.

It would be nice to see some people post some numbers about the complexity of their build, how many LODs they included, and the corresponding prim count the said object came out to be. It seems LL has waffled again and changed the way prim counts are calculated. It would be good to know what they are aiming for now. IMHO, this is the single most important factor about mesh, as if they get this wrong, it will destroy the economy.

Looks great, works great. Good work. Not perfect, but time and effort solves everything.

One of the nice features of the coming mesh design is you can make your own custom template for clothing It's a double edged sword. The downside being that without a clear standard, the market is going to fragment badly. Every creator will define their own UV mapping, and clothes from one creator will not match any other creator. You will then be tied to using only clothes from that given creator with your mesh avatar. I've seen this all too well from my years at Renderosity, and various creators making their own mesh figures (Victoria, Aiko, LaRoo,Stephanie, Poser std models, etc. ) LL's mesh may not be the best, but at least it sets a hard standard for clothing interoperability between creators. I fear that standard will be lost in the coming months/years. (at least until creators learn how bad for business it ultimately is)

Not sure, but as a follow up question, can multiple items use the same bones? Or are we going to have conflicts where a jacked wants to use the same bones as some other item? Inquiring minds want to know.

It's in the Facebook TOS. They may not have evicted you yet, but if anyone ever alerts them to your avatar account, it will be deleted.

When this beta starts, is LL going to provide people with specific information about Mesh and their implementation? It's all fine and good to say: "Rigging is is attachment based; if you import a mesh with compatible bone weight information, you will be able to use it as an attachment that will animate along with your standard avatar." But without the documentation to explain how it's done, it doesn't help. The documentation should come well in advance of the beta, so people have time to read it, understand it, and begin implementing it.