Tag: Materials Processing

SL project updates week 15 (2): Materials, AO capabilities and group bans

Posted on by Inara Pey

Server Deployments Week 15

  • As reported in the first part of this week’s update, there was no Main channel deployment on Tuesday April 9th, the result of issues arising with the previous week’s RC deployments, which LL wanted to fix rather than having them propagate across the grid
  • Magnum retained the same package as week 14 (Monty Linden’s next batch of HTTP updates) and a fix for a crash mode
  • Continuing issues in getting the anticipated updates for the BlueSteel and LeTigre deployment packages ready meant that on Wednesdays April 10th meant that these two channels received the same package as the Magnum RC channel.

The switch-out with the Magnum code being deployed to BlueSteel and LeTigre meant that those regions “lost” the new LSL Animation Override capabilities – existing scripts using the capabilities will still run, but new scripts using the functions cannot be compiled.

Materials Processing

Viewer Update and Documentation

Discussing the materials project at the Open-source Development meeting on Wednesday, April 10th, Oz Linden indicated that an updated version of the project viewer should be available shortly – possibly by the end of the week, as  “lots of fixes are accumulating”. In the meantime, a mixture of Linden Moles and volunteer users are working on materials-focused updates to go into the Good Building Practices guide to help other users get to grips with materials processing and optimising things for SL use. In the meantime, the Materials Data information on the SL wiki continues to be updated.

As pointed out by Mona Eberhardt in the comments relating to materials in this blog, Laverne Donat has produced a very tidy and short demonstration of materials in SL, which I’m including here.

Alphas, Transparency and Costs

Laverne also asked, via Plurk, if and how a specular map can have transparency with the materials processing, before going on to comment (via my blog) that, “After some testing, it seems that you can get specularity with diffuse maps with alpha masking, but not with diffuse maps with alpha blending. I don’t know what the intended behaviour is, but that’s how it works at present.”

This prompted Geenz Spad to reply, “The intended behavior (eventually) is that alpha blended objects will be able to support both normal mapping and specular mapping. Currently this is a work in progress, and due to its current state, it hasn’t been added to the viewer just yet.”

As Alpha Blending is currently the Alpha Mode which is unaffected by the materials / LI accounting situation which has been reported by Qie Niangao, I asked Geenz if Alpha Blending was liable to “trip over” into the LI accounting system, rather than being “grandfathered” (as currently appears to be the case). He further clarified the situation by replying, “Only if you use other material parameters (such as specular mapping, normal mapping, etc.). The only reason why we didn’t add support for shiny on all semi-transparent surfaces, is because it would break content.”

Future Development

In terms of future development, it is unlikely that anything will be happening soon, other than enhancements / fixes for what is currently in the project viewer. While there is a roadmap for future features and additions to the materials system, the Lab is wisely not commenting on plans and direction at this time. Rather, they prefer to see what the overall take-up with the new system is over time and how people start using it (which may in turn affect how and what the Lab decides to do with regards to a “materials round 2”). However, one thing which does appear to be clear is that there are no plans within the current roadmap to extend materials processing to include avatar skins and clothing layers.

AO Capabilities Update

New server-side AO capabilities: udpates delayed until week 16
New server-side AO capabilities: updates delayed until week 16

Although it did not get deployed in week 15 (but should see the light of day in week 16, commencing Monday, April 15th), the update to the new AO capabilities which should have reached BlueSteel and LeTigre is intended improve compatibility between the new animation override system and other scripted objects that animate avatars (such as poseballs). The update was developed as a result of Code Violet raising a JIRA (BUG-2164) pointing out that the new capabilities did not “play nicely” with things like sit animations in poseballs / furniture.

Maestro Linden, speaking at the Best Server meeting on Thursday, April 11th, described the situation thus:

If a user had a custom ‘sit’ animation set, the seat wouldn’t be able to stop the animation properly because if the seat called llGetAnimationOverride(“Sitting”), it would get an empty string unless the exact animation also happened to be in the seat’s inventory. Kelly has a nice solution to this problem, which is to make ‘llStopAnimation(“sit”)’ stop your custom animation, if you had overridden your sit animation. Conveniently, this change means that existing poseballs won’t need any updates to play nicely with the new AO system.

The Beta Server meeting saw some discussion on the new AO capabilities, which enabled Maestro and Kelly Linden to offer further clarifications.

Continue reading “SL project updates week 15 (2): Materials, AO capabilities and group bans” →

SL projects update week 15 (1): Server and viewer; materials and land impact

Posted on by Inara Pey

Upate April 10th: The BlueSteel / LeTigre package did not deploy as planned due to problems getting the updates completed in time. The Magnum package therefore deployed to all three RC channels.

Server Deployments Week 15

Second Life Server (Main) Channel

There was no planned deployment to the Main channel on Tuesday April 9th. The next scheduled deployment will be in week 16 (week commencing Monday April 15th). This was because there were bugs found in both of the RC releases from week 14 which the Lab wanted to resolve rather than having them propagate across the grid.

Release Candidate Channels

All three Release Candidate channels remain on the same releases as week 14, the only updates to be deployed on Wednesday April 10th being:

  • BlueSteel and LeTigre (currently running the new server-side AO capabilities) – should receive  a design change to improve compatibility between the new animation override system and other scripted objects that animate avatars (such as poseballs). This may be in response to a JIRA – BUG-2164 – being raised in relation to conflicts between the new AO capabilities and poseball systems
  • Magnum (currently running Monty Linden’s HTTP updates) – should receive a fix to correct a crash mode.

As always, there is a forum discussion thread for the week’s deployments.

SL Viewer Updates

CHUI – Communications Hub User Interface – Flickering Issue

The CHUI merge with the SL release viewer has brought with it an increase in the ATI/AMD issue of clickable links in the viewer’s UI flickering when anti-aliasing is enabled (BUG-1560, relating specifically to cards running the 12.10 (or later) Catalyst). This tends to happen with links in the chat window, but may also affect the selection box surrounding items in the inventory floater.

Those encountering the problem should consider raising a bug report.

Materials Processing – Land Impact

The most notable update to the SL viewer has been the release of a project viewer for materials processing. The viewer is available on the SL wiki Alternate Viewer page, and the code is available on Bitbucket. However, due to the work still going into the project, both come with caveats:

  • It is still very fragile
  • It is still subject to change in various ways
  • It should not be used on content you care about – particularly if said content is MODIFY / NO COPY
  • It is not recommended that TPVs integrate the code into their release viewer at the moment due to the fact the code will be changing (and there is not SSB merge as yet).

The release of the viewer has also brought with it something of a concern.

Qie Niangao has been carrying out further tests with the Materials Processing project viewer, and has come up with evidence that aspects of the material system can result in objects experiencing sudden (and potentially large) Land Impact value changes. Specifically use of the Alpha Masking and Emissive Mask options when working with alphas can have unexpected results – which is not to say that the result are not unexpected behaviour from LL’s perspective.

Qie describes his discovery in MATBUG-13, is which he offers the following exercise:

  1. Create a sphere. Hollow it 95%. Add a simple rotation script.
  2. Set the Alpha Mode to Alpha masking. Note that the land impact is now 43. “More info” shows the extra weight attributed to Physics.
Using the Alpha Masking and Emissive Mask Alpha Mode options with tortured prims (in this case a hollow sphere) into the "new" LI accounting system
Using the Alpha Masking and Emissive Mask Alpha Mode options with tortured prims (in this case a hollow sphere) can lead to a inflation of LI for an object

Qie goes on to note that cutting or squashing such an object can have an even more dramatic impact (path cutting the sphere in half, for example, can push LI to 1348, while squashing it almost flat can lead to an LI of 154).

Commenting on the JIRA, Maestro Linden notes:

This is expected behavior. When a material is added to an object, it is enrolled in new prim accounting. A 50cm, 95% hollow sphere has 43.5 physics cost when using a ‘prim’ physics representation. This high cost is caused by the high complexity physics shape. See https://wiki.secondlife.com/wiki/Physics_Optimization for a guide about how to reduce physics cost.

It is interesting to note, however that the same prim using Alpha Blending retains the same physic cost, but only generates a LI of 1. As Alpha Blending is essentially the way alpha layers are currently handled by the system at the moment, Qie’s theory – which I agree with – is that the existing system as been somehow “grandfathered-in” to the LI accounting system.

Continue reading “SL projects update week 15 (1): Server and viewer; materials and land impact” →

Playing with materials processing in SL

Posted on by Inara Pey

Update, April 10th: Use of some of the mateirals processing capabilities – notably Alpha Masking and Emissive Masks – can have a significant affect on Land Impact valuse – see my week 14 SL projects update for details.

On Monday April 8th, Linden Lab released the first public cut of the Materials Processing project viewer. As the server-side of the materials processing support was deployed to the main grid earlier in the year, this release means that materials processing – with some caveats – can be experimented with by all.

These caveats are that the viewer is still very much an alpha release, and as such is both subject to change and should not be relied upon as a primary viewer for everyday use in SL. Also, as elements of the viewer may change before it reaches a release status, it is viewed as advisable by LL that people do not use the materials capabilities on MOD / NO COPY items.

So how does it all work? I provided an introduction to materials processing as it applies to Second Life back in 2012. However, the following will hopefully provide a summary for those who haven’t kept up with the news as well as providing a look at the viewer itself.

What is Materials Processing?

Materials processing is the combining of various computer graphics “maps” to significantly increase the level of detail that appears on any object or surface within a computer game. Within Second Life, textures (themselves a form of computer graphics map called a “diffuse map”) are used to add detail to in-world objects and surfaces. The new materials processing capability will introduce two further kinds of computer graphics map – normal and specular –  to Second Life which can be used alongside textures to dramatically increase the detail and realism of objects and surfaces.

  • Normal maps are a means of faking high levels of detail on an otherwise bland surface by means of simulating the bumps and dips that create the detail. Normal maps can be created in several ways – such as from a texture (diffuse) map using a suitable graphics application (and plugin, if required), or by producing a high-quality model (mesh) and using an overlay process to generate a normal map which can then be applied to a lower-quality model of the same object (i.e. one with a lower triangle count) to simulate the same level of detail as the high quality model, as shown below.
Using a normal map to enhance the detail on a low-polygon model
Using a normal map to enhance the detail on a low-polygon model. The image on the left shows a model of some 4 million triangles. The centre image shows a model with just 500 triangles. The image on the right shows the 500-triangle model with a normal map taken from the model on the left applied to it (credit: Wikipedia)
  • In the real world, every highlight we see in an object is actually the reflection of a light source. Surfaces reflect light differently to one another, depending on a range of factors (material, lighting source point(s),  etc.). Specular maps simulate this by allowing individual pixels in an object to have different levels of brightness applied to them, giving the appearance of different levels of light being reflected by different points on the object. Like normal maps, specular maps can be produced in a number of ways, both within 3D graphics modelling programs and in tools like PhotoShop.
A rendering of a lemon using diffuse, normal and specular maprs to create a life-like look and feel
A rendering of a lemon using diffuse, normal and specular maps to create a life-like look and feel

The new capabilities in Second Life allow diffuse (texture), normal and  / or specular maps to be applied to in-world objects (prims, meshes), to achieve a much greater level of realism in their appearance.

First, Create Your Maps

In order to use the new capabilities, you must obviously have the required maps. These ca be created in numerous ways,  and I’m certainly not qualified enough to give a hands-on demonstration myself. As such the following are intended merely as possible pointers.

Normal maps can be readily produced directly from an associated diffuse (texture map), which may be the most common way to do so. Both Photoshop and Gimp, for example, support normal map creation in this way, each using a suitable plugin. Photoshop uses the nVidia normal map filter for example, while Gimp uses a plugin of its own. There are numerous tutorials available on YouTube explaining how to create normal maps using either Gimp or Photoshop and these plugins.

Left: A diffuse map (texture); right: a normal map created directly from the texture
Left: A diffuse map (texture); right: a normal map created directly from the texture

As a user of Gimp, I found the following tutorial by vscorpianc  provides a sold look at getting going with normal map creation, as it covers installing the required Gimp plug-in and also offers-up various resources for image files to play with, if you don’t have anything suitable yourself.

For those working with mesh, there are also various ways in which to produce a suitable normal map – including, as mentioned above, using an overlay from a high-quality model on an identical model of lower quality. Again, as I don’t use the likes of Blender, Maya, et al, You Tube offers what appears to be some easy-to follow tutorials for those who need them.

The same is true for producing specular maps within various graphics applications as well – such as bond1TGC’s tutorial on Specular Map Creation Tutorial or Aleks Markelj’s detailed tutorial Using Photoshop to create Diffuse/Specular Maps.

Continue reading “Playing with materials processing in SL” →

Materials project viewer released

Posted on by Inara Pey

Update: subsequent to this article being published, the Lab issued their own blog post on the new project viewer.

Linden Lab released a project viewer for materials processing on Monday April 8th, to go with the server-side support already released.


Materials Processing video demonstration

This is very much an “alpha” status viewer, and as such comes with a series of caveats, including:

  • The viewer is still very fragile
  • It is still subject to change in various ways
  • It should not be used on content you care about – particularly if said content is MODIFY / NO COPY.

As Oz Linden wryly commented at the Open-source Dev meeting where the release was announced, “Regular attendees may notice some small changes in my raft…. I had to reconstruct it because I messed it up playing with this viewer (mostly my fault).” So, if you plan to download and play with the viewer, be warned!

For information on the materials project, please read my overview.

The download itself is available on the Lab’s Alternate Viewers wiki page.

Related Links

SL projects update week 14 (3): Viewer releases, server-side AO

Posted on by Inara Pey

Server Deployments – week 14

On Tuesday April 2nd, the Second Life Server (SLS or Main) channel received the interest list update which has been running on the Magnum RC channel for weeks 12-13, together with fixes for the following issues:

  • BUG-1779 – Updates for objects that are out of view are delayed for a maximum of 5 seconds, at which point they will be sent
  • BUG-1795 – “Agent appears in incorrect position to other agents after being moved by a sim teleporter”
  • BUG-1814 – “No object updates from vehicles after some region crossings” – yes, the vehicle region crossing bug fix reaches the Main channel (and should be on BlueSteel and LeTigre following the RC deployments on Wednesday 3rd April).

Deployment release notes.

On Wednesday April 3rd, the Release Candidate (RC) channels received the following updates:

  • BlueSteel and LeTigre received the same package as week 13, which includes the new Animation Override LSL capabilities together with the following:
    • The changes deployed to the Main channel on Tuesday April 2nd
    • A fix for BUG-2134 – “Avatar pre-jump is sporadic”
    • Release notes are available (BlueSteel link)
  • Magnum received Monty Linden’s new server-side HTTP updates – release notes.

SL Viewer

There has been some activity within the various viewer channels, and the promise of more to come.

The Communications Hub User Interface (CHUI)

CHUI has now reached the  viewer release channel with LL issuing viewer 3.5.0.273444. This release includes both the new CHUI UI for conversations, etc., as well as a lot of additional refactoring of code. A blog post has accompanied the launch, complete with Torley’s original video on the interface.

Server-side Baking Viewer Code

The viewer-side code for Server-side Baking / Appearance (SSB) reached the SL development viewer with the release of version 3.5.1.273529. With CHUI now in the release viewer, SSB should also be appearing in the SL beta viewer view shortly.

Materials Processing

“Materials is actually making great progress,” Oz Linden reported at the Open-source Dev meeting on Wednesday April 3rd. He went on to say the latest work on the code is showing promise and was due to go to LL’s QA department. If things go well with QA, it is possible that a project viewer could finally be emerging from the darkness. However, as Oz again warned this will only happen when, “We’re confident that 1) it won’t do any serious harm, and 2) it’s not so terrible that it’ll give the project a black eye.”

Nevertheless, things are moving.

Server-side Animation Override Capabilities

New server-side AO capabilities coming soon
New server-side AO capabilities: LSL functions now being deployed to main grid

While the new Animation Override LSL capabilities have only just rolled-out BlueSteel and LeTigre, the server has actually supported overriding animations for over a year; it has just lacked the required LSL functions and some bug fixes. This means that if you use the new capabilities on either BlueSteel or LeTigre, any animations you set will continue to work across the entire grid until you log out.

In noting this at the Server Beta user group meeting on Thursday April 4th, Kelly Linden went on to say:

The new override functions do not allow setting by UUID. My original version (well over a year old) set by integer constants. However there was some desire internally to make the system more flexible, to allow for different states or modifying the state machine diagram, and for that string constants were used. Right now those string constants are converted to integer constants for use in the existing internal state machine.

In other words, the system allows animations to be specified by name (string constant), making the capability somewhat more user-friendly than might have been the case has UUIDs for animations been required. The the string constants are converted to integers for handling by the server’s state machine (the “engine” for animations on the server-side) means that it should be possible for the state machine to be updated in the future without potentially breaking content using the capabilities.

In answering a question on the lack of support for animations such as idling and typing, Kelly again explained that some animation types are not supported by the state engine. These are either handled within the viewer (idling) or elsewhere in server (typing), as such they fall outside the new AO capabilities. Swimming is also excluded, although Kelly couldn’t remember if that is handled viewer-side or elsewhere in the server.

HTTP Updates

Monty Linden’s ongoing HTTP work reached the Magnum RC channel. For those interested in monitoring SL’s port usage, Monty provided a quick summary in response to a question on texture fetches posted to the deployment thread:

The Texture Console speaks truth for texture fetches, either http or udp.  If that is quiet while this transport is going on, it’s something else …. and here are some rules that will determine the traffic:

  • Port 12046 but textures are quiet => mesh fetches
  • Port 12043 (corrected, was 12042) => other HTTP services (“Capabilities”)
  • UDP port 12035, 13000-130XX => simulator communications

Related Links

SL projects update week 12 (3): viewer, CHUI, SSB, materials and releases

Posted on by Inara Pey

SL Viewer Updates

The SL beta and development viewers saw end-of-week updates in week 12, with the beta viewer rolling to release 3.5.0.272486 and the development viewer 3.5.1.272521, both on March 22nd.

The beta update is primarily focused on CHUI, and may be the final beta release for CHUI before the it appears in an official release version of the SL viewer (see below).

On March 20th, the Sunshine project viewer (Server-side Baking) updated to release 3.5.0.272211, which may be the last releases of the SSB code as a project viewer prior to the code arriving in the SL beta viewer – see the SSB section of this report (below).

Communications Hub User Interface (CHUI)

As indicated above, the Lab is hoping that CHUI, the Communications Hub User Interface, is now in its final beta viewer run with the release of 3.5.0.272486, and that the code should be appearing in the release version of the SL viewer, possibly later in week 13 (week commencing Monday 25th March).

CHUI: probably making a final appearance in the SL beta viewer prior to appearing in the release viewer
CHUI: probably making a final appearance in the SL beta viewer prior to appearing in the release viewer

However, TPVs are still considering how best to tackle CHUI in terms of integration and deployment in their viewers. Part of the problem here is that for some TPVs, the CHUI user interface changes conflict with changes the TPVs have themselves made, and so consideration needs to be given as to which parts of the UI updates and changes a given TPV wishes to adopt. A wider issue, however, is that CHUI also includes a large about of v3 code refactoring, all of which needs to be considered for implementation into views, particularly those which are v3-based.

Further, as most TPVs have been focused on SSB updates, it may take a while before CHUI itself appears either in whole or in part, in some third-party viewers.

The CHUI updates don’t only impact TPVs – there is a knock-on effect with some of the upcoming changes / code contributions flowing into the SL viewer code as well. For example, the viewer side of the request teleport feature (STORM-1838), which I originally commented on in week 4, has been delayed while it is re-worked in light of CHUI-generated changes.

Server-side Baking

Viewer-side SSB Code

Following-on from the recent pile-on / load tests carried out using the official viewer (Thursday March 14th) and Firestorm (Friday March 15th), the Lab believes that the viewer side of the code is doing “quite well” in testing, with both tests recording very similar results, including hitting the same problems related to inventory fetching / rezzing issues for attachments.

As a result of this, the Lab have been looking at releasing the SSB viewer code to the SL beta viewer (with CHUI integration) on or around April 1st (week 14). However, the discovery of a bug with the latest version of the SSB project viewer code ( version 3.5.0.272211), may delay matters.

SUN-57, raised by Tonya Souther, reports a fix for earlier issues (non-public JIRA SH-3941 and SH-3954), now appears to cause avatar bake fail issues when running the viewer-side SSB code on regions using the current avatar baking mechanism. Whirly Fizzle has been able to reproduce the issue when using pre-saved outfits in her My Outfits folder, and describes it thus:

Replace outfit with a ready saved Outfit A from My Outfits folder (Right click -> Replace current outfit). Relog Usually, but not always, I will see part of my baked textures as grey with this certain outfit A. This session my torso texture appears grey to me. My torso fully rezzed without needing to rebake in about a minute.

[Now] Replace outfit with Outfit B, which is a ready saved outfit from My outfits folder (Right click -> Replace current outfit).Outfit B bakes fast & looks correct to myself.

Wait 30 secs or so [and] replace outfit again with outfit A. My avatar will then show the correct head and lower baked layers from outfit A but my upper/torso layer will be that of outfit B.

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: left – Outfit A from her My Outfits folder replaces whatever she was previously wearing, and appears correct; centre – after a relog, she replaces Outfit 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

Whirly further reports that the issue doesn’t resolve itself after several minutes, and rebaking using CTRL-SHIFT-R has no effect (other than reducing her to a cloud in other people’s view), while using Edit Appearance also fails to clear the problem.

Again, this issue only occurs when using viewers incorporating the latest SSB code, and only on regions which are not themselves running the server SSB code. It is of concern because the viewer code is designed to work with both the current baking mechanism and the upcoming SSB mechanism, and will be expected to do so during the SSB deployment to the main grid, when there will be a period when both the “old” and “new” baking services will for a time be running side-by-side as the latter is gradually rolled-out.

Continue reading “SL projects update week 12 (3): viewer, CHUI, SSB, materials and releases” →