Suggestion to LL

You're getting enough but reports for 1.9.1, so I've come with a little suggestion.

Stop ignoring your users! Not everyone has $4000 gaming rigs.

Please disable all these blingy features by default! Let US decide what our systems can handle. Maybe then you'll stop getting "OMG 1.9.1 SUCKS! IT KILLED MY FPS!" threads.

If 1.9.1 is released with vertex shaders enabled, I imagine a lot of people with lower-end systems cease logging in to SL.

Alot of people are pretty concerned about the next big update, including me. We shouldn't have to have a pc built by NASA to be on SL. Everytime these new fancy blingy features are added, my experience dwindles. I really could care less about flexible attachments but I know some people think it is just the bombdizzle. My main concern is why old bugs haven't been fixed instead of bringing out more features that will surely create more problems. What I am seeing is new features being brought out to try and get our minds off of the issues that need to be fixed and that's not how it should be done.

I have read about invis prims not working anymore and I am not happy about that at all. So basically all my shoes etc that use invis prims will look like crap? What about the increased drain on the servers with the new fancy flexible prims? I have seen complaints about it already and that's just in a preview grid, what about when it hits the main grid with 5000 people on at a time? How long is this going to be previewed before it is brought out? I certainly hope for quite some time and isn't rushed like they all seem to be which brings about more updates to fix the bugs the last one introduced.

I'm all for new features and moving forward, but past and present issues need to be fixed before bringing in new...

Flexy prims don't drain servers. Client maybe . And ew, nasa would be like buying a gateway.

People wouldn't have "lag" problems with the updates if LL would just disable the shiny new graphics features. I bet they're all runnin' NVIDIA 7800 graphics cards at the office and forget that not everyone can afford $800 for a graphics update.

Our poor lower end cards just can't run with software designed for the high end cards.

I do believe that the problem with invisiprims is being looked into. When I went into preview yesterday there was a Linden rep tellin' people how to temporarily solve the problem. So they ARE aware of it.

I dunno, I mean, my system is hardly a $4,000 gaming rig, although it WAS built especially for gaming.

That said, I do always go over the preferences with a fine-toothed comb with each update, so I guess this doesn't really apply to me.

The client has been set up to configure itself based on the capacities of the system it runs on.
The featuretable.txt file basically allows configuration based on CPU, amount of RAM and graphics card.

It could well be a good idea to reevaluate and/or expand the current configurations in that list to better conform with specific setups.

This thing you speak of...autoconfiguring to best match MY system...doesn't work. It's never worked. Ever since the computer gaming industry started doing it, it's been broken.

No two systems are alike. Even if you have the same hardware in two systems, they're never the same.

Everywhere I go in SL I hear screams of "OMG THE LAG!" Of course they're not really referring to lag; they're referring to FPS drop. And if shaders remain enabled by default, the screams will only get louder.

Just my two cents, and I hope LL takes it and puts it in the coffers.

Hi Trep,

I appreciate your concern for the users who have less than state-of-the-art machines. For those who experienced a dramatic drop in framerate in 1.9.1 preview, now is the time to speak so that features not suitable for their hardware default to disabled when the final version comes out. We do test on a variety of hardware, not just the fast development machines, but it always helps to have feedback.

Also, I'd like to point out that:

1) Flexible objects add virtually zero burden on the simulator, which sees them as identical to any other primitive; on the viewer, they are very tightly time-sliced so as to scale with the capabilities of the machine and never bring down framerate in a significant way. They are not being rushed out, they've been in development for months and internal performance testing since February.

2) Occlusion culling (on hardware which supports it) is intended to improve fps across the board, and is not a "new fancy blingy" feature. It should also allow parcel owners to reduce the influence of their neighbor's content on framerates.

3) Invisiprims will work. Content will not be broken.

If you have any other concerns, feel free to ask. My hope is that with this release framerate will rise not just in the average but more so for lower-end users. The whole reason for preview is feedback, and so specifics about what works best on your hardware are cruicial to help us deliver the best experience for all our users.

I totally agree. In my testing, occlusion culling has been great. I was standing with a wall of terrain blocking a massively primmed area, and gained between 4 and 8 FPS with it on.

On the "content will not be broken" statement: Is LL aware that the switch from top-sizing to tapering has broken some content? I'm not fully aware of the extent, but several of my scripted objects now rez previously top-sized prims "upside-down".

I filed several reports about this because I was initially unaware of how the function had changed. When I changed the tapering from positive to negative values, things appeared normal. Not sure if anyone else has reported it.

Ooh, just got a decent sounding idea: How about a warning before logging in for the first time after patching? Tell us that our preferences have been messed with. Maybe something to the effect that we should review them and to expect an FPS drop until they're tweaked. That way people who don't go over them with a fine toothed comb every time get fair warning.

Odd... I had a script using top size run as usual, but noticed that to get the "other" end to taper used the values from 1.0 to 2.0, negative values just acted like 0.0 (the usual top size zero).

I will make sure that someone tests that the top size feature didn't break scripts. If you have a repro script which behaves differently between main grid and preview, please send that in with your bug report. Although I'm not sure why it would be, since as Seifert astutely points out, the values have reversed only in the UI - the underlying value range has just been extended from 0-1 to 0-2, with 2 mapping to -1 in the UI. I believe it would be easier to explain that in the LSL wiki than to deprecate that function and create a new one.

Unfortunately, too many flex prims can make SL VERY jerky and laggy (framerate)--especially with either "all local lights" light detail setting. Better optimization needs to be done to keep framerate constant with many flex prims in-view. Perhaps reducing distance flex prim animation steps to compensate. Currently, it looks like ALL flex prim animation steps are reduced, then the client starts pausing every second or so proportional to how many flex prims there are in-view.

Also, texture animation ("slide" and "rotate" mostly, but "scale" a bit too) aren't smooth when even flex prims are in-view (I start noticing jerkiness after only 6 flex prims and a single hardware light--and my Pentium D 2.8GHz, 2GB PC4200 dual-channel DDR2 RAM, GeForce 6600GT 128MB system ain't no slouch).

It's not the flex calculations causing framerates to drop drastically when there's a lot of them in view. It's the POLYGON count. It's the one thing in all of SL that nobody seems to care about.

Have you ever looked at the flex prims as you adjust the Softness?

PEOPLE! Don't set all your flex prims to 3.0 Softness!

If someone at LL could tell us the poly count on a 0.0 Softness flex cube and a 3.0 Softness flex cube, that'd be awesome. Maybe seeing those numbers would get people to thinking about the FPS drop that THEY cause.

I don't care what video card you have. If the users of SL don't learn how to manage polygon counts, no amount of render engine improvements will help framerates. SL is a GAME! It uses GAME technology. Treat it as such, and framerates will increase.

I suspect people will be walking in completely sealed cubes that follow them around as they wander through malls and clubs to keep the occulsion running.

i dont know if anyone else has noticed with the 1.9.1 preview version, but i have broken arms in there. Some other people have also noticed misshapen body parts on themselves. I asked a couple of lindens about it and they said they will look into it.

This is not a poly count issue, however. The pauses that occur as I describe above are directly related to both "all local lights" light details options. A poly count issue would result in continuous, not intermittant (every x seconds) lag. I'd be willing to bet, though I have yet to try, that setting all flex prims to 0 softness wouldn't help in this kind of intermittant lag.

LL has acknowledged several bugs (fixed some I see) related to the new shader code. I've been writing all unknown FPS drop off as a result of these bugs. Well that and my defragger has been acting up lately causing CPU issues.

I haven't had a chance to test the latest preview version, did the problem go away for you? (doubly curious as I'm getting a shiny new 6600 card this week, thinking maybe NVIDIA driver issue)

still present in SL 1.9.1.11

My concern is with "avatar Vertex Program" which is in the main grid 1.9.0. will this be integral or separate? I absolutly cannot run avatar vertex program. without it checked i get like 15 fps even in a crowded sim. with it turned on i get only like 1.5 to 2.0. LL needs to separate avatar vertex program and make it a a separate clickable option like in the main grid 1.9.0. also, is vertex shaders the same thing? Kinda confused about this.

It appears that the avatar vertex program has been lumped together with the rest of the shaders. The avatar vertex program option is gone in 1.9.1. I would assume that "Enable Vertex Shaders" toggles all shaders.

Where is the ""Enable Vertex Shaders"? I can't see it. And I noticed that the avatar vertex program option was gone (and everyone that I know when it is turned on gives a big FPS hit and often makes their system just crawl).

-DB

*edit*
Ah I see it, must have missed it due to it being gryed out and not where I thought it would be. Oops.

Re-evaluation would be indeed a good idea, checked out this file and found it disables AGP on all ATI cards because "in Catalyst 4.3 it's at least 50% slower" ... which would be fine, except ATI drivers are now at build 6.3 i.e. underwent 20 revisions or so since then.

Don't know if it actually got any faster, but something tells me this wasn't tested in a while, either. Enabling this switch at the moment doesn't seem to make the client run any slower, at least.

It actually gives me a couple extra frames per second. I've been keeping it enabled for quite some time now with no ill effects. Also, from what I've observed, this forum needs to do alot less 'zomg Aye'tee'aie! and more 'zomg LL, compatability!' Just my opinion.

It's on the main graphic options tab in the preferences (1.9.1 only, this isn't a 1.9.0 feature).

BTW, if anyone noticed enabling Vertex Shaders made their av's hair (the body part, not prim hair) have unsightly bald patches, it's in our bug database, as well as several other problems involving Vertex Shaders which we endeavor to have a timely resolution on.