SL projects update week 16 (1): SL viewer, materials, SSB and other bits

SL Viewer Updates

There’s no movement on the release viewer, and likely won’t be until Server-side Baking moves to it, having finally arrived in the Beta viewer on April 12th (see below). The Development viewer was also updated on April 12th, with the release of version 3.5.2.273873, which includes both SSB and CHUI updates.

Materials Project

An update to the materials processing project viewer was released on Friday April 12th – 3.5.1.273855 – with a series of bug fixes included in it. There are further updates on the way, with the next release due around the middle of week 16, which will have further bug fixes and, hopefully, some Alpha mode updates as well. Commenting on the latter at the Content Creation User Group on Monday April 15th, Geenz Spad said, “Actually just got normal maps working on alpha blended objects, and trying to get everything else working on them as well.”

One fix currently pending is that for MATBUG-16, Changing one material, or setting causes another material texture to be lost. This is an issue which can happen as a result of several factors. For example, setting a normal or specular map for one face of an object can result in maps already applied to other faces of an object either being removed or replaced with the most recently added map. The same issue can occur when applying a setting such as glossiness to one face of an object using materials.

MATBUG-16 demonstrated using 2 deiffuse maps and their associated normal maps. (l) the prim with a diffuse map added to one face & with the "stone" normal map still showing for all faces. (r) the normal map add
MATBUG-16 demonstrated using 2 diffuse maps and their associated normal maps. A prim previously set with a stone diffuse map and associated normal map has a green diffuse map applied to one face – the normal map is unaffected (l). However, when the normal map is updated, it changes for the entire prim (r)

This problem doesn’t happen every time mixed materials elements are used on object faces, but can occur when adding multiple materials elements to an object in quick succession. “There are a couple of problems there,” Oz Linden said while discussing the problem at the Open-source Dev meeting on Monday, April 15th. “The updates to the server are happening faster than it will allow, which is one problem. The other is that the updates are not applied locally as smoothly as they should be.”

Tonya Souther, who re-worked the Build floater for materials processing added, “Yeah, that bug has been driving me batty ever since I first did the UI. And I think that’s due to the design of the system…the UI has to ask the server for the material separately, and apply the values retrieved from it to the UI components when they arrive. That ‘s the only way that the UI won’t get out of sync with the actual values stored on the server … I just need to find a way to make the delay not apparent to the user and handle changes that come along in that period.”

For now, the answer seems to be that if you experience any issues with normal / specular maps vanishing or being replaced when using multiple maps / effects across different faces of an object, then allow a short pause between adding the various maps / effects so the viewer and server can keep pace with your work.

Elsewhere, Geenz Spad, one of the architects of the materials processing system, has started a new blog series on materials, Second Life Materials:  A Content Creator’s Guide. In the first part of the series, he answers the question, What’s a material? In the next installment, he promises to take a look at some of the tools which can be used to create normal maps.

Server-side Baking

The viewer Server-side Baking /Appearance code reached the Beta viewer in week 15 with the release of 3.5.1.273869 on April 12th. The initial stats apparently show it is doing well, crash-wise, but the status of incoming bugs is currently unclear. However, it still looks as if the code is currently on course for around a two-week stint in the beta viewer prior to moving to the release viewer channel.

A key bug fix for the system has been SUN-57, which now allows multiple layer of clothing to be worn / swapped on regions which are not running the SSB server-side code (on Aditi), which removes a potential road block from server-side code deployment (remembering that for a time during the server-side deployment, updated viewers must support both the old and new avatar baking services).

The SUN-57 issue, as defined by Whirly Fizzle: left - Outfit A from her My Outfits folder replaces whatever she was previously wearing, and appears correct; centre - after a relog, she repalces Outfir A with Outfit B, and again, everything appears correct; right - she replaces Outfit B with Outfit A, but her skin fails to bake correctly, the head and legs showing the skin associated with Outfit A, the torso still showing the skin from Outfit B (shown naked for clarity) - images courtesy of Whirly Fizzle / JIRA SUN-57
The SUN-57 issue, as defined by Whirly Fizzle, which saw issues occurring in avatar baking using a viewer supporting the upcoming “new” SSB/A service and changing outfits on a region only supporting the current avatar baking process, which saw outfits and skins failing to update correctly following changes. Reportedly now fixed

There are still no definitive timescales for any Agni deployment for SSB/A. As previously reported in this blog, it is still unlikely that any major deployment operations will commence prior to the SSB cove reaching the release viewer.

Other Items

I recently blogged about Oculus Rift and  speculation as to whether it would see use in Second Life. On April 7th, Jon Brouchoud blogged on why SL would be a “killer app” for the headset – an article which has seen widespread reprinting / referral in SL / Opensim related blogs. While I have no particular opinion either way as to Oculus Rift / Second life (although how it will work with the SL UI does intrigue me), I have to admit the following video demonstrating Oculus Rift had me smiling from ear-to-ear. It’s not really related to Second Life, but it is well-worth watching.

Advertisements

5 thoughts on “SL projects update week 16 (1): SL viewer, materials, SSB and other bits

  1. Nalates is reporting on an issue with some very complicated meshes, taking several minutes of calculation in the Mesh Deformer process. Apparently these items have an extremely high polygon count. Based on my own experience, I suspect they were made for such programs as Poser, and got a quick and dirty transfer to SL.

    I am inclined to think that Oz, pushing for test items “Right now!” might have encouraged such things. I’ve worked with Poser, and good garments take time, even taking into account the number of polygons. Some content creator with content in the Poser world could have presented it as a test item, and maybe even warned that the polygon-count was unusually high.

    But it doesn’t need a Mesh Deformer for high-polygun meshes to be a problem in SL. They have to be passed around at every sim-crossing, way more data than anyone really needs to handle. Everyone who sees them has to download them. Done right, a Mesh object can be a good solution. But if these high-polygon meshes are the answer, somebody has been asking some damn stupid questions.

    Like

    1. I saw Nalates’ report, which came off the back of a Metareality broadcast and her own poking at mesh. I’m nowhere near qualified to comment on the technical complexities of mesh and the deformer – hence why I tend to keep coverage here on those aspects I regard a “known”, inasmuch as I can understand them and blog on them.

      I’m not sure that Nalates is commenting on high polygon counts themselves being an issue for the deformer, but rather that – as Karl points out on Metareality – the idea that the calaculations used by the deformer should be transferred server-side and carried out there is an issue for SL as a whole, due to the resulting load being placed on the back end. Nalates draws an interesting parallel with server-side baking, where the calaculations and associated data are more-or-less moving server-side – and is requiring a hefty amount of dedicated hardware to be deployed serer-side as a result.

      One of the biggest potential problems with the mesh deformer – as both I and Nalates have commented on, as has Karl himself, is that in many respects there has been a huge amount of scope-creep for the project in terms of users’ perceptions of what it could and should do. Witness the entire debate over avatar shapes / sizes. The result of shifting perceptions, etc., is that the Lab is caught between a rock and a hard place – because whatever they release now or in the future is more than likely going to severely piss off a lot of people because of what it “doesn’t” do, or “should” do or “can’t” do. In this repect, they’ve been handed something of a poisoned chalice. Of course, the flip side to this is that really, it is a shame that the Lab apparently didn’t hear / didn’t listen to questions and commentary over the potential for mesh to be used as clothing, etc., and so missed the opportunity to develop a suitable means of deformation internally when mesh support was still under development.

      Like

  2. YAY for SSB (finally), which seems to have at least ended the need to relog to get alpha layers on my torso to update and just in time to make new spring outfits 🙂

    Like

  3. Materials, Despite its bugs (Really for as new as it is, it really isnt that bad.) is awesome. I been using the viewer everyday all day since its release, and have used every feature in it available thus far. I have to say It makes so many new things possible. Many kudos to everyone who worked on it, excellent work! My next interest is the ribbon particle, and the AnimationOverrride commands. There are so many awesome new things to play with; It is very exciting times in SL. As always I will follow the meetings/meeting logs, and this blog.

    Like

    1. The viewer itself is proving very stable and suffering from few crashes. While there are bugs in the materials system, these are to be expected as this is only a “pre-alpha” release of the viewer-side code. As such, you’re abolsutely right – things really aren’t that bad, bugs-wise; it’s just worthwhile letting people know what has been spotted and, where possible, what is being worked on and what might take longer to sort out (such as MATBUG-16).

      Going by Kelly’s recent comments – in which he indicated on a personal level that he would have preferred not to have had the new particles system mentioned at a Beta Server meeting a couple of weeks back -, it would seem that the particle updates are still a way off. Again, this is unsurprising given everything that is going on with the viewer right now.

      The Animition Override capabilities should be reaching the Magnum RC on Wednesday April 17th according to this week’s deployment schedule. These include a fix for BUG-2164 (the issue of the new capabilities not playing nicely with sit animations in furniture, etc). I’ll have an update on things out later on today which should cover this.

      As ever, thanks for your support in both reading this blog and leaving comments, Mich. Always appreciated :).

      Like

Have any thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.