Several interesting things were discussed in Friday’s Server Scripting meeting.

Video Memory Compression

In pre-meeting conversation I heard a new texture compression process is being tested for storing textures in video memory. The feature is in one of the project viewers. I’m unclear on which project. While there are some video artifacts it almost cuts memory use in half. There is a Debug Setting that turns it on. It is off by default. …and I don’t know the name of the setting.

It seems the current iteration of the feature also compresses the User Interface textures resulting in some oddities.

RC Roll Outs

Simon Linden says the new software packages rolled to the release channels Wednesday are working well. Another region crossing bug was found. So, they are planning to roll the Bug Fixes package to the main grid next week. I think that means the Le Tigre and Blue Steel will roll to the main channel and Magnum’s will stay on a release channel.

llGiveInventory() Throttle

The throttle on llGiveInventory() is being relaxed. That change will be rolling to the main channel next week. The delivery rate using llGiveInventory() doubles to 2,500/15 minutes from 2,500/30 minutes.

Simulator Discussion Group

Those attending the Server Scripting Goup meetings and other server related groups are offered invitations to join the Simulator Discussion Group. This is a private section of the forum. I’m told only the reasonably sane are invited. If you are sane or can role play being sane, you have a good chance of being invited. Talarus Luan has started debate on whether the unreasonably INsane qualify… double negative and all…

New RC Packages

Simon Linden says there are not any new server maintenance packages ready for next week. So, none of the Lindens present knew what was likely to roll to the RC’s next week (10).

LSL Syntax Update

Andrew is working on the server side updates to LSL (Linden Scripting Language) syntax files. This is the change that will make an easier process for updating the script editor’s highlighting in the viewer. With 35+ new function and more options for existing functions the editor is out of date. When Andrew finishes the script editor should stay current with future changes and additions.

Andrew got all the tooltip hover text converted from the viewer to the server. He has a script that can backport the same strings from the server code into XML tooltips stuff again. Current work in progress is on the keywords.ini file.

There is a slow down while Andrew figures out how to handle missing keywords and gather their definitions.

Region Encroachment

Andrew had hoped to get a script written that enables the Encroachment Return feature in the simulators. Once enabled people will be able to return objects that encroach on their land.

Per-Parcel Avatars Limit

This idea was discussed. There is some merit to it for spreading people out in a region. But, there seems to be not great demand for the feature.

Andrew thinks a per-parcel avatar limit might affect viewer lag more than anything else. Avatar density has a significant impact on viewers.

Sim FPS and Physics FPS

Simon says in answer to a question that these two values seen in Viewer Statistics (Ctrl-Shift-1) are locked together. One or the other is likely to be removed.

Voice Control

The idea of whether voice control is possible came up. This would allow a land owner to assign rolls to people that would allow them to use voice in the area. Everyone without the proper roll would not have voice speaking ability but could hear.

Andrew says it is theoretically possible and believes one would just need to make the voice controls available in the viewer.

Don’t hold your breath. One will need to see a feature request go in and people voting/watching it to get a place in the list of Linden priorities.

Pathfinding

Falcon Linden made it to the meeting and explained about some updates to the new Pathfinding features.

Friday night or perhaps today the Lindens are going to deploy a new version of the alpha pathfinding code, which contains support for collisions with characters. Characters can receive collide() events and will interact properly with volume detect objects. As Falcon says, “Or at least, they should.”

Quoting Falcon:

In the case of a single, box-shape volume detect object and one character, it seems to do the right thing 😉 Also, all objects can now use collision_start and collision_end, not just volume detect. it’s a happy coincidence of refactoring that you get the bonus collision_start/collision_end events.

Also, terrain is no longer a height field for physics, it’s now a mesh. Should make for more efficient collisions in many cases but may lead to tunneling of fast objects. The problem is that the height field was WAY too detailed.

Vincent Nacon: so… what about edge collision issues?

It’s a “welded” mesh, so normal’s should be corrected.

Vincent Nacon: There are issues when objects [collide with] a polygon face from the [side].

Yes, but not for this mesh, at least, there shouldn’t be.

Siana Gearz: What happens if you make a terrain which has too many convexities close by each other? Won’t that behave a whole lot worse than height field?

It’ll be almost exactly as bad as what you would get if you used “set accurate-terrain enabled” previously. The thinking is that for /most/ regions which have fairly smooth terrain, you’ll get a win in performance. Especially regions with lots of collisions  (like race courses). If we find it causes a performance problem, we may add an option to go back to a height field.

Vincent Nacon: I’ve already gotten bad results from Mesh prims.

It doesn’t work like a mesh prim. Because of certain issues related to not knowing how you’d use a mesh prim, to data size and upload time, we couldn’t support welding on uploaded meshes. But we can on the terrain because we know that it’s the terrain and taking 15 seconds to preprocess that data on a background thread is acceptable. (Welding is when two more polygons meet. Welding is the process of looking at every triangle and all of its neighbors and storing information on how to handle collisions at the shared edge .It prevents you from “bumping” at triangle transitions.

Siana Gearz: So, I’m wondering what I have to learn for convex decomposition task… Does it make sense to enlarge the convex hulls and have them always overlap [and] by how much?

If you use the “analyze” functionality, you’re correct. And if the object is physical, you’re also correct. But if the mesh is not analyzed and is the /non/-physical object in a collision, its triangles are used. [There is] no need for overlap, but overlap isn’t a problem. The tool works pretty well. Just tell it how much detail you need and try to keep the total number of hulls and vertices down.

Andrew Linden: we don’t use the “concave mesh” shape for mesh objects that tumble about (dynamic, aka “physical” according to the SL UI). Instead we use convex hulls or other convex shapes for meshy objects that collide dynamically.

The new code should be available by tomorrow [Saturday] on the PathTest regions [in ADITI].

Draconis Neurocam: What happens to something pathfinding over terrain that is being modified?

The effects of terrain modification are delayed. When they do take effect, characters will behave the same as other dynamic objects, quite possibly ending up under the terrain. There is some code that tries to put underground characters back on top.

Vincent Nacon: Does this means we can apply friction setting for the terrain?

No. Someday, though…it wouldn’t be hard… Take a couple hours, if it was done with the console.

Mesh Adoption

We got a tidbit of hews on mesh adoption: 80% of the logins are now on a mesh capable viewer.

Summary

With the recent loss of Charlar it is unclear which things are moving ahead and which may be changing. It does appear that work is ongoing for improved region crossing and the Pathfinding features.