1.22 RC5 now Available

Not only is there no improvement in the texture picker, new window, people chooser etc., but textures and are taking even longer to rez for me. I give up on going shopping anymore...it just never completely rezzes. And it may be just too many users for SL to handle but the lag is the worst it has ever been for me. It is almost impossible to do anything in SL except talk to friends...the lag & texture problem just makes it impossible to enjoy creating, decorate or shop. As my desktop was built especially to enjoy SL ...it is very doubtful it is my computer which seems to be the standard answer to my whining.

I really hope the texture problem will finally get looked at and fixed. I voted on this VWR-8503 back in November but it seems although residents are all experiencing this problem...support Lindens cannot reproduce the problem. Maybe they think we are all just making it up? My impression from the few answers this JIRA has recieved is that we (the residents) have to prove to them there is a problem before they will take it serious. And even though many residents have shown detailed information on what is happening with the textures loading...they do not want to go back and read them. Instead they want residents to go out and collect all new information. I really don't get it...it is very strange behaviour from a support group for any software application in my opinion.

I will stay with the RC's in the hope that one day the texture problem will be fixed and besides....I do love SL. But it really does take away the enjoyment of coming in SL and I find myself spending less time in-world as it continues.

The ray-trace picking has also broken at least one aspect of touch detection. I have a product in development that's going on hold until VWR-11434 is fixed.

https://jira.secondlife.com/browse/VWR-11434

I didn't think picking was a huge performance problem before, I hope this "improvement" isn't just a result of somebody's CompSci master's thesis.

I'm also annoyed that we went to the trouble of buying premium video cards on LL's reccomendation and now find we have to lock texture memory to 256m (our cards have 640) to gain stablity (VWR-8841). Like to see some explanations on that one. Zen Linden said there's "driver bugs above 512m"...I'd want to know the nVidia bug numbers for those so we can press nVidia for fixes.

Looks like VWR-8503 is where the party is on this stuff now.

All the 1.22 RCs so far have not showed the x,y,z co-ordinates of the last selected prim in the edit menu. I know that the co-ordinates show at the top of the main screen, but this is no where near as accurate as being able to see the last selected x,y,z info in edit when dealing with builds made up of multiple unlinked items.
Surely other builders must have noticed this too?

Texture loading is real slow in RC5 for me. The other RCs loaded textures fine. Actually, texture loading is now slow in the other versions I use as well (1.21.6 & 1.20.7). This seems to coincide with the 1.24.10 server release.

I've done some experiments today with different viewer versions and nVidia drivers after some people complained about low FPS and slow viewer behaviour in general. I could partly reproduce that, when starting the viewer for the first time it was indeed pretty laggy. That changed with closing and restarting. There seemed to be some issues with initializing graphics.

When updating I usually uninstall and delete the user_settings folder that includes the settings files from the previous version(s). One interesting finding was when I installed the 1.22.5 RC for the first time, it removed not only this but deleted the whole Application Data/Secondlife folder. Something older viewers did not do. Obviously there are issues with old settings and thats a safe way to force a clean install.

After all my old settings were gone, suddenly the slow down issue disappeared and all went smooth again. Not only for the 1.22.5 but also 1.19 and 1.21 viewer (1.21 was affected most by the FPS).

This may not exactly help with the slow loading of textures you experience, but it may be related. From now on I will get rid of all old stuff in that Application Data folder when changing viewer versions. Suggest you give that a try too.

In XP the folder to delete after uninstalling a previous version and backing up your chat and IM logs is: "C:\Documents and Settings\<your account>\Application Data\Secondlife"

That's not an acceptable requirement. Even resetting graphics settings in the RC viewer is marginal but understandable. If specific settings need to be reset that's one thing, but throwing away all settings... let alone discarding everything in the profile (including logs)... is unacceptable.

PS: SL is still not *using* the "test day" settings in the day cycle editor, but at least it's not throwing away the windlight lighting settings the way it used to.

After uninstalling and installing the numerous versions I use (and clearing App Data) it seems that I cannot get RC5 and a production viewer to coexist on my machine and have textures load in a timely manner (timely ~ relative). It's either one or the other. But still, RC5 texture loading is poor.

I installled 1.22.5 on Vista and my logs are still intact. Thank goodness.

I completely agree. But from my experience and from many other people who ran into problems with different viewer versions that was the safest way to get a stable environment. This is specifically the case when you run different versions the same time like I have now 1.18, 1.19, 1.20, 1.21 and 1.22 in different builds and update them frequently. Surely not the recommended and supported configuration. But even when you define separate settings files for each version there are still other settings written into the avatar and Secondlife folders.

To me it is not really clear what goes where and when and why and from whom. But certainly settings get screwed up this way. That's nothing to blame LL for and not related to the 1.22 RC, it's just a fact in such a setup with many versions we should take into account. To go through a standard preferences setup from scratch takes about one or two minutes. Thats worth the trouble it saves. So I recommend this for CV users.

The logical thing to do is to have the RC use a different application setting folder, IF the situation is really that dire.

It's possible to do this and I've done that before. The Application Data folder is hardcoded in lldir_win32.cpp for the Windows version (CSIDL_APPDATA). This refers to the environment for all Application Data for all Windows. Easiest way to isolate the path is to put it to an unused one like My Pictures (CSIDL_MYPICTURES) or My Videos (CSIDL_MYVIDEOS) and define the virtual folder (still flexible configurable) in Windows. Alternatively one could hardcode it in the viewer.

May be feasible for a test build, but not really useable for a production viewer.

After all the picking comments, i'm not sure if it was already mentioned or is in the JIRA: I can't pick linden tm trees anymore, when the cursor is on the leaves. They are handled like an alpha texture. Wasn't that way before.

Now i have to pick the trunk to edit a linden tree, what can be pretty difficult from the distance.

Btw, the new Nvidia driver 181.20 at least doesn't cause any problems ...

Boy Lane, thank you for the hint, i didn't 'clean install' the viewer for a long time ... I will try if it makes any difference.

I have been trying to post this since two days, till i found out why i wasn't able too ... i was using the word 'select' in my post, see jira WEB-917 ... that's really a crazy one ...

Better and more portable, use the --channel argument to determine the folder name. Or add an --appname parameter. You don't want to put it into "MYPICTURES\Second Life", you want to put it in "APPDATA\Second Life Release Candidate".

If this kind of requirement is still there when you get to release, you have bigger problems.

I don't mind resetting prefs so much. But I don't want to go through an elaborate dance to preserve my logs, especially when I can be forced to a new RC with zero notice.

Hello,

I've recently got a new laptop, which has an Intel 965 graphics chipset. I've tried to run SL with this laptop, but SL tells me that it cannot run as either the drivers are out of date (which they're not) or the hardware is unsupported.

Can anyone suggest a quick workaround, without having to buy a graphics card?

Thanks in advance.

Smokey, as far as I can tell without knowing the exact revision of the 965 integrated graphics your laptop has the chipset is capable of handling OpenGL (required for SL) up to OpenGL1.5. However, the drivers for it that come with windows or you get from windows update "typically do not include support for OpenGL" (quoting from doco on the Intel website) - MS prefer folk to use DirectX for 3d rendering on windows but since SL was always intended to be a cross-platform thing, OpenGL was the logical choice. You may be able to get a driver from intel.com that both works with your windows version and supports OpenGL but if you cant then you are SOL without upgrading to discrete graphics, typically only available as a factory option on laptops.

(edited to add... verify that SL is OK with OpenGL1.5 and take full backups before installing the Intel driver. Your laptop may be using enough custom stuff from the manufacturer that installing the generic Intel driver for integrated components can blow your system away back to "recovery disk required" level)

Totaly agree with you. I lost 6 month of IM history and I was about to open a JIRA issue for that.

The Intel video chips from that series are adequate to word processing on XP but not much more; in fact there's a significant industry brouhaha over the fact that Microsoft certified them as being Vista-ready despite the fact that they don't really meet the defined performance standards.

I wish I had a happier answer for you. And I don't envy you the task of trying to upgrade the video hardware in a laptop. Hope the driver-based suggestion that Da5id made proves helpful.

Has anyone else noticed that scripts in child prims of an attachment fail under 1.22.5, but have no problems under 1.21.6 ?

Short version:

I've create scripts that use MoveTo to perform movements of an attachment. When inserted into child prims, it seems only the last few prims are usable with my scripts (which uses control to maintain operation in non-script areas), but the object works well in 1.21.6.

When using viewer 1.22.5, the same object will stall if the avatar looks at a busy group of avatars, or enters a non-script zone. Status checks of the scripts also fail, so it's not just the 'MoveTo' code having problems.

The reason for using child prims is to reduce the communications overhead involved with using multiple listening scripts in the same object. The performance gained is easily seen as real.

What's the difference between 1.21.6 and 1.22.5 that would cause my working object to fail?

Update:

After spending a day trying to find out why the scripts fail, I find that I'm unable to reproduce the problems the next day. The only changes that had occured was that the sim was rebooted and I changed the video card fan, as it was running too hot.

I still have a problem with memory persistence of assigned Controls with scripts in child prims, but that is minor.

I suppose I'll chalk it up to a sim glitch or an overloaded sim (Waterhead).

Has nothing to do with the channel. The CSIDL folders are pre-defined in Windows and can be bent to some other location. That makes it still flexible rather than using a hard coding. I used that to put all my SL settings in an F: drive within Truecrypt on my laptop

First, you get the UUIDs of everything visible.
Then you pull in the textures you have in cache, regardless of the distance.
Then you start pulling textures from asset, starting with the 20x20x20 cube in front of the avatar. When they are all fetched and cached, you then fetch for the 40x40x40 cube in front of the avatar. And so on and on until the cube dimensions meet the draw distance. THEN you fetch the rest of the textures in the sim.

The upshot is that nearer items rez first and you don't waste the first few seconds getting a texture 90m behind me behind a mountain ridge. Focus on what's in front of you and visible first, then the rest of the sim. Using a cube for culling makes computation fast and comparisons easy; Xmin < Xitem < Xmax and likewise for all three dimensions, you fetch its texture.

Regarding - http://jira.secondlife.com/browse/VWR-8818

This bug was reported for 1.21 but is still present. This really affects the ability to create, sort inventory, report griefers, add people to groups or ban lists, etc etc. Anything that requires a second look into the inventory lags terribly and gets progessively worse each time a new window is opened. I had the texture picker lagging over 4 min last night, during which the client is frozen.

WHEN IS SOMEONE GOING TO QUIT PLAYING WITH ALL THE BLING AND FIX THIS MAJOR PROBLEM FOR CONTENT CREATORS????

I am so tired of the bells and useless whistles getting attention when truly major defects such as the one above, or the fact that alpha textures don't display correctly, go un-resolved.

Come on Lindens - lets get some of the issues from 3 and 4 months ago fixed - ( almost 2 years for alpha texture issue) and leave all the bling and add-ons until you have a stable client and world again.

DRD

Or, rewrite the entire client.

When a program gets to the point where it's near very hard to fix bugs without creating more and more, it's time you ditched it to program another.

I'm getting the feeling that the original creators of the client are long gone, or all the bug fixes and improvements have made the code so utterly messy, it's hard to keep track of what code does what.


Second Life v2.0!


We can only dream!

The problem with alpha sorting is caused by how the video card draws objects on the screen (near to far). There is no fix for it short of changing how video cards work, which should happen in a few years when hardware gets fast enough for real time ray tracing. Until then you can do what professional game developers do and not put alpha textures so close together.

Better algorithm:

1. Get rid of the current texture cache. Replace with with a 3-level UUID-based file cache similar to the squid cache the sims use. Let it get as big as the user wants. If the user wants a 50GB cache, do it, squid's simple directory tree works just fine for that.
2. When looking up a UUID, if it's in the cache, use it, otherwise request it.
3. If the file in the cache is incomplete, use it anyway and just request the rest of the file.

On the server:

Sort the interest list in order of distance from the camera, instead of leaving it in sim object ID order, so that the client sees objects in order of distance from the camera instead of approximately the order they were rezzed in the sim.