Update June 21st: A new Materials Support and Tips thread has been started by Creator Linden in the Building and Texturing Forum (with thanks to Daniel Voyage for the poke).
Server Deployments – Week 25
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (Main) Channel
On Tuesday June 18th, the SLS main channel received the interest list improvement project which have been previously deployed to Magnum (week 22) and BlueSteel and LeTigre (week 24).
Release Candidate (RC) Channels
On Wednesday 19th June, all three RC channels (Magnum, BlueSteel and LeTigre) received the same server maintenance package, designed to fix a number of crash modes and address an issue with neighbouring region visibility. In addition this package:
- Contains the new LSL pathfinding property CHARACTER_STAY_WITHIN_PARCEL, and the new LSL object return functions designed to assist land owners with the return of objects under controlled conditions
- Provides fixes for A fix for an issue in which LSL HTTP-in scripts would sometimes see the incorrect URL (BUG-2833) and for Bug 2850 (Cannot rez objects in Bluesteel and LeTigre parcels which disallow object entry).
The neighbour region visibility issue fixed by the deployment is for SVC-8019, which is related to issues with regions failing to communicate with their neighbours for up to an hour are a restart, causing communications issues (e.g. LSL chat) across region borders, rather than being related to the issue of diagonally adjacent regions not being visible to one another (SVC-8130), which is still an issue on the main grid.
Commenting on the latter issue while testing it with an alt during the Server Beta meeting on Thursday May 20th, Maestro Linden said, “It looks like some kind of false communications timeout in the remote region, where it disconnects your viewer.” Currently, there is no proposed fix for the issue, although the Lab keep poking at it.
Materials Processing
The Materials Processing project reached a release status on Wednesday June 19th, with the release of Second Life viewer 3.6.0.277516.
However, problems continue to be reported with transparencies rendering as black when using the viewer, (see MATBUG-175, MATBUG-193 and a similar bug, MATBUG-186).
Two possible workarounds for these problems have been suggested, which may work, depending on the precise nature of the issue, if you’re experiencing it:
- Going into Preferences > Graphics and unchecking Advanced Lighting Model (ALM) before click OK to apply, then going back into Preferences > Graphics and enabling ALM once more
- If you have water reflections set to Minimum in Preferences > Graphics, try setting them to a higher value and then unchecking / rechecking ALM.
Some of these issues were known well in advance of the viewer reaching a release status, which promoted comments of surprise during the Open-source Developer meeting on Wednesday June 20th that the viewer had been released. Commenting on this, Oz Linden responded:
I’m not at all surprised that people found combinations of visual attributes we hadn’t tested that were busted, really. There are a staggering number of combinations – after you factor in all the possible settings changes on top of them, the number is absolutely not even close to something we could test. The “black issue” makes it sound simple…. we probably had a dozen bugs during development that had that same symptom for different reasons. I’m sure we’ll get it sorted out.
There have also been reports of alphas “not behaving correctly” with the new viewer release (see here), although this may also be the result of gamma correction now being included in the viewer code by default.
In terms of gamma correction, people are noticing that some scenes render a lot darker with the materials viewer than when seen with other viewers, and have raised bug reports on this. However, as I commented in my beta release overview of Materials Processing:
Another change to the viewer is that it now include gamma correction. This means that there is a chance that scenes rendered in the Materials Processing viewer will render differently to when seen with a non-materials viewer. How differently scenes render when compared to non-materials viewers will depend on a variety of elements (brightness, time of day light, scene content, etc). This isn’t a bug, it’s a result of the updates made to the rendering system.
In discussing the darker rendering, Wolfbaginski Bearsfoot offers a guide to monitor settings which may provide additional help to those finding scenes unusually dark compared to older viewers.
Some concern has also been raised over the potential performance impact of having up to two additional maps for the viewer to load and render (normal and specular), particularly given the over-use of 1024×1024 textures. Responding to this, Oz said, “Well, there are potentially two more textures to load, but we’re also making a lot of changes to improve that as a general matter.” It’s also not clear whether the additional maps get loaded into the GPU’s texture memory or not (mainly because those who had worked on that side of the viewer were not at the meeting to address the question).
Materials Resources
The official resources available for materials is growing, and for anyone interested in working with materials / trying it out, should refer to the following:
- Second Life’s light model for materials – SL wiki
- Case studies for creating a wooden crate, a katana (June Dion) and a sequined bear
- Materials FAQ – Linden Lab
- Good Building Practices wiki – Linden Lab
- Content Creators Guide – Linden Lab
- Materials Support and Tips – SL forums
Other Items
Rendering Adjacent Regions
Following the discussion of the SVC-8019 and SVC-8030 issues affecting neighbouring region visibility at the Server Beta meeting, Lucia Nightfire raised a comment / idea on rendering adjacent regions in general:
I have a beef with how the interest list works with adjacent regions versus draw distance and how far from a region center your cam is, there’s just too much redrawing and memory use increase prematurely, I truly wish we had a switch/button to turn on/off “Render adjacent regions.” You just opt out of being a child agent [and] make sure you reconnect when turning it off. [It’s] not rocket science in making that feature, would be a killer savings on downloading and memory usage, graphics card usage, everything.
Concerns were raised that were this a viewer-side change, it would impact those who do wish to view other regions and would lead to delays on region crossings, as Voidpointer Linden commented, “One downside to that would be a large delay in region crossing at it has to download the rendering data and not use any cached data”. This is turn prompted Lucia to further explain the idea:
It’s an on/off switch for when it’s needed or not, if they want to cross regions they can turn it off, I’m telling you, it would be a major bandwidth savings for both parties and ease the burden on slow connections graphics cards, and memory, to me its win/win for all. I mean you’re not querying adjacent regions for data.
Whether or not bandwidth saving per se would be produced as a result of such a viewer-side change was subject to debate, although the merits, viewer-side, of such an option were seen as potentially worthwhile, as Voidpointer again commented, “Yeah, rendering speed could be better on the viewer by just ignoring the data for the other regions, but if you want to actually save bandwidth, the server would have to be modified to not send the data in the first place.”
It is liable that the idea will be put to Linden Lab as a formal feature request in the near future.
Inara Pey: Living in a Modemworld 
Maybe the Interest list was a bad idea?
LikeLike
I’m not sure if “bad idea” is the right phrase, although there are clearly niggles / upsets with the system. It’s certainly fair to say that the updates have many benefits which can be appreciated (even if some pass unnoticed by the majority of us). The new camera clamping updates tend to largely lead to a more predicable experience in camming around (unless you are camming out over very large distances), allowing smaller objects to correctly rendering in your field of view than was previously the case. Scene loading is much more predictable with items reading much more in a near-to-far order than was previously the case (again, allowing for massively-high draw distances), etc. Then there are all the “under the hood” improvements which lighten the load on the server, the viewer and the connection between the two, and so on.
In terms of Lucia’s idea, it potentially has merit regardless of the interest list changes inasmuch as it might offer a more flexible approach to using SL by allowing users to select how they want to “see” and interact with the world, with the freedom to toggle between “modes” depending upon what they’re doing at the time and what they want to see.
LikeLike
I do find the switch approach the wrong message.
If one thing LL should promote is places like Bay city or Blake Sea, those places are made to be traveled along, crossing sims on a natural way.
Same with LL railroad system!
LL should promote travel without the need of using teleport, not the other way around!
LikeLike
It’s about providing choice, not about promoting one method of in-world travel over another.
If such a control were to be implemented viewer-side, it would make no odds to you (or I) as people who like to sail / fly / drive / use the mainland trains. We’d simply have our viewers set to how they function today (which would likely be the default were such a capability to be added).
However, it could potentially provide those who do want to benefit from some local performance improvements the ability to do so. And there are certainly valid use cases for adding such an option (combat enthusiasts, for example, might benefit for only having their viewer load data pertinent to the region in which their combat is taking place).
LikeLike