SL project news week 6 (1): servers, viewer, materials

Deployments for Week 6

A full set of deployments on the channels this week.

On Tuesday 5th February, the Main channel received the server maintenance project deployed to LeTigre in week 5. This has miscellaneous minor bug fixes and new features – release notes.

On Wednesday 6th February, the Release candidate channels should receive the following:

  • BlueSteel should receive code for materials processing. There is still no project viewer publicly available for this project. When one becomes available, notices will be posted on the Project Viewer page, the Tools and Technology Blog, and STORM-1905release notes
  • LeTigre should receive a new maint-server project to fix miscellaneous crash modes, and which  offers minor performance improvements – release notes
  • Magnum should receive an update to the interest list code and support for materials processing. The interest list update should specifically address the bot / bandwidth problem reported on in last week’s updaterelease notes

As ever, a forum thread has been created for the discussion of the deployment packages, or any issues arising therefrom.

In late 2012 some regions (noticeably Homesteads) starting experiencing issues related to their physics memory. Investigations by Simon Linden revealed that part of the problem lay with these regions experiencing repeated navmesh rebakes, with each rebake consuming server memory with the result that multiple rebakes were leaving regions in need of a restart. Simon also confirmed that not all of the triggers generating a request appear to be linked to the actual need for a rebake (altering some estate / parcel settings can trigger a request, for example), and developed a fix for the issue. Simon believes this fix will be promoted to a Release Channel this week, although it is absent by name and description from the release notes at present.

Viewer News

Viewer releases are again unblocked, with further development viewer (incl. CHUI) made at the end of the week 5. Currently, CHUI looks to be the next project in line to be merged to the 3.4.5 code (with the project version already merged to the viewer-dev 3.4.6 code). This could make CHUI the first of the current projects affecting the viewer to reach a beta viewer release, but the timescales and order are far from definitive at this point – so it is possible CHUI may still be delayed in reaching the 3.4.5 beta code.

Materials Processing

Further to the week 4 update, it now appears scripting support may become available with  materials processing, although a) it will not be in the initial release; b) there appear to be considerable concerns on the Lab’s side of things as to the potential impact. Speaking at the Server Beta meeting on Thursday 31st January, Maestro Linden said the option for scripted control of normal and specular maps had been removed from the original proposal out of concern for it being exploited and used to thrash the server and rendering pipeline.

Speaking at the Content Creation User Group meeting on Monday 5th February, Geenz Spad, who co-authored the original proposal and who is working on the viewer side of the project, struck a more conciliatory tone. While confirming script support will not be available for normal and specular maps, he commented that this is in part because normal and specular maps don’t “plug into” existing means to manipulate diffuse (texture) maps using scripts. He went on, “I’m not saying no one would add scripting for the *new* parameters. Just that it won’t make it as part of the first release; think of it as a ‘we didn’t have time’ sort of thing.”  Whether or not support for scripted control of normal and specular maps remains to be seen, commenting on the matter, Nyx Linden said, “That would be a feature request to submit after the first release :),” – so it is likely the Lab will see what the demand is like prior to committing to anything, one way or the other, again allowing for the network / rendering concerns which have been voiced on their side.

In terms of animating normal and specular maps, Geenz confirmed that all current methods of animating textures will work with the additional maps, which I had more-or-less confirmed through my own rough tests, as reported in my sneak peek at the (then) latest version of the pre-release materials viewer.

Back in week 3, I discussed the fact that normal and specular maps require a viewer to be running in deferred mode (“Lighting and Shadows” in the Advanced options of the Graphic tab in v3-based viewers) in order for their effects to be seen, and gave a short overview how deferred can be used without actually having to have shadows enabled. This post was followed by a short discussion on possibly renaming the option to something more obvious to users.

Well, it appears that someone is a few steps ahead of things on this. In the most recent versions of the pre-release materials viewer, Lighting and Shadows is renamed to “Advance Lighting Model”.

Materials processing: the option formerly known as "Lighting and Shadows" - soon to appear in a project viewer Materials processing: the option formerly known as “Lighting and Shadows” – soon to appear in a project viewer

It’s still a little bit of a mouthful, but it may help when it comes to explaining how materials processing works. As it stands a project viewer for materials might be available by the end of week 6.

Other Items

What’s in a Name?

Those who make  full permission items intended for use by other creators as a part of their products can often face a frustrating problem: finding themselves in receipt of a call for assistance about the items in which their products have been used – as it is their name recorded in the Creator field, rather than the name of the person who made the item itself.

While this can be negated in some degree, results aren’t always perfect, and requires no small amount of fiddling around when it comes to full perm mesh items. This being the case, there was some discussion at the Content Creation user Group Meeting on Monday 5th February as to how the situation might be improved through the introduction of an additional field which could sit alongside the Creator and Owner fields and  which would identify the person who utilised a full permission mesh in their own work as well as the maker of the mesh itself – so that support questions could then be addressed to that person. One suggestion has even been to call the new field “Support”.

However, such a change could have wide-ranging impact, both in the viewer and server, making it a potentially complex matter to implement. During the Content Creation meeting on Tuesday February 4th, it was clear that there were several views on the subject of how to handle things, as well as some discussion on the complexities of actually implementing it.

Commenting on the matter, Nyx Linden requested that if a consensus view can be reached on the matter – or if people do feel it is a pressing matter which needs more consideration / discussion – that it should be raised as a feature request on the JIRA (i.e. file a bug report, but put “Feature Request” in the title / subject), so that it is at least on the Linden radar.

13 thoughts on “SL project news week 6 (1): servers, viewer, materials

  1. Regarding the Advance Lighting Model, I wonder where the “Point lighting” drop-down menu went.


  2. It does look a little as though people are getting confused about the difference between “scripted” and “animated” textures.
    The usual animation method is to use a large texture storing several frames of animation, which are showed by a combination of scale and offset settings, with a special LSL command making the details simple for users.
    What seems to be scaring the Lindens is the prospect of new textures being loaded by a script, and so having to be distributed to all AVs within sight. This isn’t how animation is done, because of the inherent delays. I have seen this done for such purposes as alternative colour schemes for vehicles. It is less load on the system than deleting one object and rezzing another with a different texture.
    On what’s been reported, I’m inclined to think that Geenz Spad know what happens in-world rather better than Nyx Linden does.


    1. From what I can gather, the concern is with the second part of your comment: that scripted control of the additional maps could be exploited in a form of UUID flipping across three maps per face of a self-replicating prim, impacting the renderer and bandwidth (much as UUID flipping was used with sculpts in the past).

      Whether this is a valid concern or not (and indeed, how big an issue flipping UUIDs for sculpt maps may have been / is), I’ve no idea.


  3. After the way Niran was treated, I’ll be surprised if anyone bothers to open a JIRA for Nyx. The Lab continues to do its best to drive away those who want to make Second Life better. One day, they’ll get me too.


    1. There definitely does appear to be some failing of comprehension in the matter of OPEN-162, unless I’m missing something very basic.


    2. Niran has the problem of assuming that breaking existing content is good, because it means future content will will better. Open-162 underlines this, as has various conversations I’ve had with him in the past.

      Unfortunately, breaking existing content is a very bad thing for SL, regardless of what people may think. It’d require many content creators to fix their now broken content, require customers to get updates for their products, and for the people who bought content from people who don’t even use SL anymore, they’re just out of luck. It’s a massive logistical hurdle, and it’d more than likely create an even bigger divide between the community and LL.

      Although Niran did propose an LSL script that would “fix” the incorrect attachments in that JIRA, there is zero guarantee that people would actually use it. Most people would see the fixed behavior as bugs, and flood the JIRA with bug reports as a result of the fix.


  4. A loss to all that really enjoy SL in all its beauty, cause it looks like no other Tpv developer understands how a good gui and amazing graphics can make all the difference, but we do!


    1. To be fair, the vast majority of what Niran was doing was nabbed from other viewers and patches with a few values tweaked to make things look “prettier”. The only things particularly unique about his work was the GUI, which is always highly subjective.


  5. Materials have my undivided attention. However reading about them is losing its edge. I need something stronger… a viewer on my Linux box.


    1. Patience, you must have, young padawan. Reward then you shall have :).

      Shouldn’t be much longer before a project viewer is generally available.


  6. Geenz, all tpv’s take and use others tweeks!
    But show me another viewer that shows and uses the graphics as Niran’s!
    Just to shame you all, the others Tpcs devs and even LL:
    Tried Exodos latest release, Dolphins as per 24Jan, Catnip latest, firestorm latest, Singularity latest, Zen before went down.
    All using the max graphics settings that each viewer allows!
    None is close to Niran’s performance and quality with extreme shadows enabled.
    None but exodus use tone mapping and ambient oclusion.
    All make World seem dull.
    Exodus, the 1 that i consider being the closer to Nirans, uses the v3 reg gui, without pie menu!
    In all, fps where lower with worse graphics settings then Niran’s running at the extreme settings that allows!
    So until you show me a viewer that handles my gtx580, my win 7 64b, my 12giga ddr3 and makes it worth, please spare me your (and i bet many other devs as well) talk!
    As none (And i already posted that i think that, and dont come with the lame excuses of being work for free) of the devs of tpv that still work, seems to care about visuals, all i can say is, SHUT UP or release 1 that replaces the graphics quality of Niran, on modern computers!


    1. Ambient Occulsion is a standard option in all viewers, and has been for some time – as are the options to adjust it. All Niran’s viewer does with it (as with Exodus and Firestorm to name two others), is to present the settings through the UI.

      As to “caring about visuals” – you should remember that Geenz himself is leading the viewer-side implementation of the forthcoming materials processing for SL (and is being supported by other TPV developers). He was also one of the co-authors of the proposal put to LL to have materials added to Second Life. Finally, he is also looking toward adding gaama correction to the official viewer (which will in turn filter through to TPVs).


    2. Back in the day, Exodus was the only Viewer to support features such as Gamma Correction, Color Correction, and HDR Tone Mapping. Niran has naturally incorporated these features to his viewer, but if you want to go on about how Niran’s is the only one that’s capable of looking as nice as it does, then you’re sorely mistaken.

      Tofu’s features (which Niran states that he uses) are intended for eventual upstream inclusion. My own features are slowly making it upstream as well, with the materials project no less.

      Niran has largely just incorporated our features with every XUI modification he can thank of. This is what Niran does. You can get identical looking graphics in Exodus with some tweaking, and other viewers that include Exodus’ rendering features.


Comments are closed.