Flexiprim and hardware lighting on/off preference box

Just the option to leave flexiprims and hardware lighting off on our computers, whether its on or off by default. Staying on across sessions would be good.

In the preview, there are two toggles for "Vertex Shaders" - one under preferences, and one under debug. Also, there is a toggle for flex-prims on/off under debug. I'm not sure whether or not the flex-prims toggle stays put across sessions though.

ah ok coo I usually crash in the preview becaus eof massive particles or whatnot. My last trip i didn't but every texture except prim attachments (oddly hair too though) was solid pitch black.

what would you want to see instead of flexiprims? nothing at all? because if you just dont render them as flexy and have them solid, given the way they have to be linked to flex properly many things are just going to look ridiculous - like tails will stick out in a straight line up in the air instead of flexing gracefully to the ground with a little tension, flexy sleeves and stuff would appear as a cylinder hammered vertically through peoples arms, etc. Builds using flexi would end up with random weird bits sticking out all over. Trees and plants would be random clumps of prims - I made various things like this in preview and was setting and unsetting their flexibility, and you simply cant recognise what the hell it even is when flexy is off.

Of course, if you just turn them off, people will be half dressed, hairless, builds missing parts etc.

What would you propose and prefer? It's your view of SL thats going to look like crap either way, though

Though, personally, I have not seen any impact on performance even when viewing hundreds of complex flexiprims. And I made a point of trying to link a stupid amount of them just to see whether it would have any noticeable performance hit.

Exactly. Me and groups of friends have been doing "hair" parties in the test grid where we all don our high prims hair and dance around in large numbers. Even have multi-color rotating lights going on bump-mapped walls. What did all this add up to? Almost no slow down at all. Easily far less that an area loaded with torus hair. Not to mention, it just looked awesome. =)

My views going to look just fine. We don't need flexiprims or hardware lighting. we need bug fixes.

Besides, I don't want to be distracted while I work around the box office device

Free events for everyone!

I SERIOUSLY find it hard to believe so many flex prims and lights aren't slowing you people down cuz they start making slide/rotate texture animation jerky to me even with just 6 flex prims and a SINGLE hardware light. ~32 starts slowing down flex prim animation and gets incrementally slower proportional to the amount of flex prims.

What is your light setting? Mine's on the highest (all local lights + shadows) and I have a pretty fast system: Pentium D 2.8GHz, 2GB RAM, GeForce 6600GT 128MB.

If you disable flexible prims: on avatars you don't see them at all, on other objects they appear but are not flexible.

Not always, especially if the object is linked and/or scripted, which tend to just make the flex prims disappear (and don't usually reappear until unlinked or flex prims are re-enabled. However, there are also issues with linked flex prims even appearing when rezzed from inventory.

Not to say the flexing prims are over loading the cashe and causing people to crash or lockup...

I'd like to point out that there is a difference between tons of flexible prims destroying your frame rate and the same number of flexible prims updating very, very slowly. The original assertion was that flexible prims don't reduce viewer framerate significantly, and if that is the case then it should be preferable to update them rarely rather than never, as they should assume some semblence of the intended shape with a few updates. Even if the tail doesn't animate, it still has the shape of a tail.

Now if someone is suggesting that their framerate is reduced by 20% or more, then please send me your average FPS before and after toggling Flex Prims in the debug menu, and if there's a strong demand I can scale down the simulation even further for those with low Object Detail settings in their preferences. Keep in mind that since it's already time-sliced, users with slower CPUs are already simulating fewer flexible objects per frame, and in hardware tests the framerate hit associated with flexible objects was not correlated with CPU or GPU speed.

I would love to do this if i was not always crashing....or doing a hard reset.......

Oh tell me this. is a 3200 amd 64 cpu a slow speed?

Well, even with a lot (say, perhaps, 64 flex prims and multiple lights--say, max hardware and a couple software), SL will pause every second or so as everything updates or whatever. Specifically, this is most noticeable to me in Morris--not around my stuff in the southeast, thankfully, but if I move to the north where Vecktor's rotating multi-colored flex prims are, the "pulse lag" occurs; worst in west Morris where I average 3.5fps. Setting lighting detail to "nearby local lights" boosts framerate up to ~24fps! "Sun and moon only" gives another ~5fps.

The 2 "all local lights" options are seriously degrading framerate with lots of prims around.

i'm curious eep, what is your PCIe link width?
x1, x2, x4, x8, x12, x16, or x32

Strangely enough, from all 3 computers I've tested at home (wildly varying hardware), flexiprims seems to have the least effect on my framerate of ANY of the options that can be enabled and disabled on the client, even when there's tons of them. Hardware lights also seem to have little effect, even on my laptop.

The two lighting options besides Sun and Moon only and Local Lights Only are of course going to be slow, as they are using the same software local lighting that 1.9 and before were using. It uses baked in vertex lighting in software. If your computer has problems with Local Lighting on 1.9, neither of those two options are going to improve it at all.

I think the slow texture animation is a completely different issue involving how often objects are updated in the client, because it seems that, depending on how much precessing the client is doing on various things in the area (flexiprims, non-phys prims with llTargetOmega, and prims with texture animations I believe), it will update those objects slower and slower, keeping the overall framerate consistent. I think this is the appropriate approach to take.

edit: I also wanted to add that my main computer I use SL on is an old Athlon 2400+ with a Radeon 9600 with 1.5GB ram. My AVERAGE framerate in a regular sim is usually sub 15, but I like to have stuff like shiny on. From everything I've been able to test, flexiprims seem to really do nothing for my framerate either way, but they do look cool. Same for the hardware lights. I used to experience the mysterious pulse lag, but somehow, it went away recently in 1.9 when I wasn't paying attention, and hasn't been back since.

x16

Not when the framerate drops to 3.5fps like it does for me in west Morris.

I seriously doubt that. Set your light to either "all local lights" or "all local lights (+ shadows)" (which ARE hardware for the 1st 6 user lights, then software thereafter), go to an area with at least 6 flex prims and 1 hardware light and you should start to notice slight lag (can see it easiest on slide/rotate texture animation)--probably with even less prims with your older system than mine. Then, keep adding more flexprims and lights. Or just go to west Morris and grind to a near-halt of 3.5fps (less with your system).

My settings:

1. all local lights (+ shadows)
   
2. 64m draw distance
   
3. anistropic texture filtering
   
4. ripple water
   
5. shadows
   
6. bumpmapping/shiny (should be split up, incidentally, LL)
   
7. vertex shaders
   
8. occlusion rendering
   

I'm not saying this isn't the case, although I think that you are mistaken about the lighting. Per Robin Linden's post at /16/e1/100128/1.html:



I haven't been able to actually see more than 6 moving lights in a scene anyways, since I never turn on the other two options. As seen in the quote above, there are no hardware lights moving lights drawn past the original 8. All other lights shown are only static lighting that has been 'baked' by drawing colored vertices on the ground vertex mesh to simulate lighting. That is why it takes so much memory to do it, as well. I think the whole point of even introducing the hardware lighting was so that people with lower speed processors but decent (DirectX 9) video cards would be able to have some form of 'neat goodie' to keep the scenes dynamic. On any decent video card, the overhead from hardware lighting should be absolutely minimal in this implementation. I believe your loss of fps is due to the fact that the software method SL uses to shade the ground in 1.9 and so far in 1.9.1 (it may change in 1.9.1) is pretty slow. Activating the higher two lighting methods would have just the same impact as activating 'local lighting' would on the main grid, i.e. fps vacuum.

-edit: I just realized this is probably a different issue. You were probably referring to the way that 'smooth' texture animation did not appear to be so, which the supposedly fixed in the one of the latest patches for 1.9.1.

Yes, llSetTextureAnim framerate was much increased (though it still lags a bit with lots of flex prims around) in 1.9.1.14 (despite it STILL being in 1.9.1.16's known issues list). However, this particular slow-down issue was improved, if not completely fixed (undocumented, of course), in 1.9.1.14 also, I believe. However, something has changed yet again the lag is back (in a lesser degree) in 1.9.1.16 with SL freezing at random intervals for random time periods with lots of prims (not necessarily flex) and either "all local lights" option on.

I'm not totally sure if it's the same issue, but I do have SL freeze sometimes, usually when zooming within a certain distance of tori (i.e., my hair). I have absolutely no evidence whatsoever to back it up, but it certainly FEELS as if the pause is caused by the engine calculating the new faces for the LODs on all of the tori. Since tori (and any 'rounded' objects, spheres and cylinders to a lesser extent) have an exponential amount of faces generated per LoD, it's quite possible that zooming in to a certain amount can create litterally thousands of faces in that instant. This would lead me to believe that prims are not actually meshes with LODs precalculated, as I originally thought, but actually some kind of procedurally generated mesh, which the client creates.

... at least it sounds good, and could explain the freezing.

-edit: I should word that better... it's obviously not just limited to 'zooming in', which implies the camera, but merely coming within a certain distance of the particular object. It's also possible that LODs are calculated per linked set (for whatever reason) instead of per prim, which might also explain why it freezes all at once. Or maybe not.

SL LOD is calculated on-the-fly (and has always been like that for as long as I've been in SL). This is not an SL 1.9.1.x issue. However, there might be an issue with SL 1.9.1.16's LOD calculation and hardware lights and/or occlusion rendering but it's hard to tell with the "shaders" settings so screwed up now. I'd rather have each setting separate so I can test it more easily and know what is screwing up than having to try a bajillion different combinations just to enable/disable setting--ridiculous UI design, LL!

eep remove the anisotropic filter its a heavy draining feature for little gain

Never had a problem with anistropic filtering since upgrading to a GeForce 6600GT. The problem is either "all local lights" option, flex prims, LOD, and/or a combination of all of these.