Andrew Linden talked about caching in the 9/13 Simulator User Group. He has the job of writing code to track cache misses. I’ve never thought the viewer cache was doing much for me. I don’t see much difference in render speed for returning visits to places I’ve visited from places I’ve never been to.
The trick is figuring out which are planned or expected misses and which are cache failures. If you have been to a region you should have all the needed textures in your cache. Those textures should be found and avoid the need for a download. If the texture is in the cache and it downloads again, it can be considered a miss or failure.
Of course if you have never been to a region, one expects all the texture to have to download. So, misses are not a bad thing. The challenge is in knowing when the caching system is failing. It has broken in the past. So, the new code will be an alerting system.
The simulator has an Interest List. In the list are the things the viewer needs to render the scene for its avatar. As Andrew describes it; when an avatar arrives in a region things around them have specific positions, geometry, and textures needed to render them. The simulator figures out what objects are in the avatar’s view and assembles a list that it sends labeled with a version number. When things in the list change, a new list is sent with an updated version number.
When the viewer gets the list it looks through the local objects cache for objects with the same version number. Then sends a list of all the things it does know about (misses) to the server. The server uses that data to make a package of the missing items and sends the package. All the packages are kept in the cache. If you leave/logoff and then return to a region all the packages should still be in the cache. The number of cache misses should be very low.
Andrew’s code is to implement a system that will alert the Lab to higher than expected cache miss rates.
Andrew thinks they are seeing some improvements since the kernel upgrade… I did not know that had happened. The prime purpose of a Kernel upgrade is to solve the TimeWarp problem. SVC-6689 – Sims Performance Substandard due to “TIMEWARP”.
Andrew thinks the Lab is on debian/etch and wants to move to debian/lenny.
Mesh Bloat and Returns
It is possible to scale up a mesh object until it exceeds the prim limit. It then gets returned as the last object changed. Andrew tells us that is being changed. The simulator will look at the future scaled cost of the object. If it exceeds the region’s prim limit the scaling will be disallowed.
The system is imperfect and the estimated scale cost may not match the real cost after scaling. The real cost computation requires use of the physics system and is too resource heavy to be used for real time estimates.
There is also a situation where two objects are being scaled up simultaneously. Both may be estimated to fit within the limit. But, when both rez and are recalc’d for the real value the combined value exceeds the limit.
Fortunately the code to return the most recently changed object is in place and working. This new code will return the object even if it is still selected.
Then there is the odd case of having more than one parcel to base prim count on. Build one over its limit but within the combined limit and all is well. If the second parcel is abandoned, the over built parcel will start returning things. The last changed order does not apply in this case. Things are returned in this order:
1st objects owned by others from newest to oldest. Parcel owner and group owned are excluded from this selection and return round.
2nd objects owned by the parcels affiliated group returning from newest to oldest.
3rd objects owned by the parcel owner from new to old.
Top Scripts Reporting
Estate managers have noticed that script load for estate manager tools and the viewer stats report hugely different values. See SVC-3819 – “Top Scripts” in estate tools is inaccurate. Kelly says a fix went into one of the release channels this week… or next… whatever. Kelly says even after the fix they will probably not be showing exactly matching results.
We are getting info about this new feature from various places. Kelly and Andrew say we may be able to adjust the wait time on llCastRay via the Estate Manager tools. This would allow region owners to adjust it for their needs. It seems obvious that a combat region would have more demand on it then a shopping mall.
We’ll hear more about this as they learn more about how it behaves and is used in SL. Expect more news when it reaches the RC.
(More llCastRay below)
The Lab has done a lot of work on improving region crossings. Some have found that when wearing NO scripts they can cross a region boundary and not notice it. Vehicles are still a problem. More work on region crossing is in progress.
If you are planning to go streaking, you shouldn’t have problems with crossings.
Jeremy Linden does documentation. He does lots of work in the SL Wiki. He created a new page a couple of days ago. It is a new set of Mesh Frequently Asked Questions (FAQ). The new Land Impact terminology is used.
SVC-7283 – llRemoteLoadScriptPin and llGiveInventory fail when installing non-full perm items into worn attachments. This has been an annoying problem. Oskar discusses it:
This was an unfortunate situation. Our RC process is a very solid [testing] process. But it does not accommodate security fixes very well. We can’t really have SEC- fixes in an RC for 3 weeks because people will realize we are fixing those issues.
So, we need to release [security] things faster and without warning. Unfortunately in this case we caused another bug. This puts us in an awkward position because we can’t really roll back the fix and we don’t want to shove another fix out hastily.
We have long, sometimes heated, discussions internally about how to proceed. In this case we decided to put the fix on an RC next week and offer to move affected regions to the fixed RC. Then we can give that RC priority the next week. It’s not a perfect solution and we apologize for the bug getting out.
The previous candidate rolled to the main grid, which fixes; SVC-7169 – Folders are Texture Category Folders, SVC-7192 – llSetMemoryLimit – Wrong amount being reserved for memory/Display inconsistence with OBJECT_SCRIPT_MEMORY, and SCR-162 – Bounds error when calling PRIM_LINK_TARGET in a child prim.
This upgrade included some server crash fixes too.
This channel got a mesh maintenance package. This includes PRIM_PHYSICS_SHAPE_TYPE for llSLPP and friends. Also llGetPhysicsMaterial() and llSetPhysicsMaterial() are testing. They let one set the friction, gravity, restitution, and density of an object via script.
llCastRay() is enabled in the Blue Steel and Le Tigre Release Channels. It seems the feature is very limited while testing. SCR-199 – Reduction/removal of llCastRay limitations, SVC-7289 – llCastRay() returns RCERR_CAST_TIME_EXCEEDED on small parcels.
Kelly and Falcon Linden are working on how to reduce the restrictions.
Bugs fixed in Blue Steel are; SCR-53 – llSensorRepeat not triggering no_sensor unless a sensor event handler is present, SVC-34 – Right-clicking another Resident’s moving object freezes it, SVC-6970 – CLONE – Object losing permissions when some prims are unlinked,
I’m not sure… I’ll update this if I have time tomorrow.
New Movement in SL
Falcon has been working on llSetKeyframedAnimation(). This will let people move things through a non-physical link set. Elevators, doors, and trains that run on tracks could all use this function to achieve smooth movement. Additionally, you can stand on these things while they move. Falcon says, there are no limits except that it must use the new prim equivalency system and be under 64 physics weight. He also says there are animation issues.
So, while the avatar can walk on a moving llSetKeyframedAnimation object the animation will mess up. That is caused by a problem in the server miscommunicating what the avatar should be doing.
You can find the rough documentation in the wiki as: llSetKeyframedAnimation().
The feature should soon be working in two ADITI regions. Check out the wiki and look at llSetKeyframedAnimation()’s TALK page. Falcon said he would post when the regions are running the function.
If you play with the new function and find a bug, include the function name in the JIRA issue title.
Summing It Up
I have two meetings mixed together here. Also the timing of which moved to grid and which to the Release Channels is a bit confused… or at least, I am and it is too late to look up the info to unconfused it.
It seems that mesh is getting fixed. That seems to be freeing time to implement other things and fix other problems. New features are fun.