SL project news week 43/2: SL viewer, mesh, and materials processing

SL Viewer News

Things are not looking good on the official viewer front. As previously reported, the crash rate for the 3.4.1.265898 beta release was unacceptably high when compared with the current release version.

A new beta candidate  – 3.4.1.266073 – was released late on Monday 20th October. As per usual, it will remain on the beta channel for a couple of days once released in order for LL to get a read on performance and crash rates. Some regression testing has started, with the beta code merged back to the viewer-development pipe, but work is really pending on confirming the beta code is relatively stable.

In the meantime, feature changes to the official viewer remain frozen, and even should the new beta release prove stable enough, it is going to take some time for LL to prioritize all of the pending updates (both their own project work such as the Steam updates, HTTP project, Group Services, etc., and contributed updates), start merging them into the code, testing them, and then releasing updates once more.

With regards to overall viewer stability, A series of crash fixes from Firestorm (officially viewed by Linden Lab as the most stable viewer connecting to SL) have been contributed to LL and are awaiting regression testing in order to confirm their effectiveness with the LL code.

Mesh Deformer

A new version of the Mesh Deformer project viewer appeared over the weekend – 3.4.1.266081, dated October 20th. This has the revisions Darien Caldwell has made to the uploader and custom shapes, although she is still waiting on feedback from Qarl on the matter of the sliders / bone armatures which are deformed by both the viewer and the deformer, as mentioned in part 2 of my week 42 update.

The new version should hopefully include a small bug fix when selecting the Default Male shape (which would act as if the Default female shape were selected).

Materials Processing

Materials processing: using a normal and diffuse (texture) map to generate a 3D effect on an in-world wall – coming to SL in the near future

Speaking at the OpenDev meeting on Monday 22nd October, Oz Linden indicated that the specification for the revised build floater in the viewer – needed to handle picking, rotating and offsetting normal and specular maps in the same way as can be done with textures (diffuse maps) at present.

The specification for the floater has been written in-house at LL, but the work is being undertaken for LL by a third-party viewer developer who volunteered to carry out the required work on LL’s behalf. This work will initially focus on getting a shell for the floater built, as there are a number of things that are being worked on within the viewer with regards to making parameters actually visible on surfaces.

Discussing progress at the Content Creation Improvement Informal User Group on Tuesday 23rd October, Geenz Spad outlined some more of the upcoming capabilities, as defined by the initial release specification document.

“We have normal maps with specular exponent stored in their alpha channel, specular maps will have environment masks stored in their alpha channel [so, for example, mesh won’t require seperate faces in order to have different levels of shininess on different parts of it], and for diffuse maps you’ll be able to select to some limited degree what its alpha represents (currently, none, alpha blending, alpha masking, and emissive mask).” He went on, “There’s a few additional knobs people will be able to mess with as well, such as specular exponent (combines with the normal map’s exponent map in its alpha), specular color (combines with the specular map’s color), and environment intensity (combines with the specular map’s alpha).”

However, custom environment maps – such as used with custom reflections – won’t initially be supported, as has been previously indicated. With the initial release specification now locked – but not currently open to public reading, that will occur nearer the time LL are ready to make a further announcement on materials – any additional functionality is being looked upon as being either for a further release or requiring a programmable system to implement.

Whether there will be further updates to the system remains to be seen, but it appears those involved in the project, both inside and outside of LL are reasonably confident there will be. “Materials is something that you can likely expect to receive several updates over time,” Geenz commented. “It’s something that’ll evolve from a fixed system into something a fair bit more sophisticated eventually.”

Related Links

4 thoughts on “SL project news week 43/2: SL viewer, mesh, and materials processing

  1. I’m really looking forward to seeing Materials in widespread use.
    There is a lot of stuff on the Marketplace that is essentially shiny–latex, leather, oiled skin, and much else of that more-or-less fetishistic sort. And, instead of baked-in highlights, do it with Materials. As for chrome and other metallic effects. go for it.
    Some of these things currently depend on clothing layers, and getting them in the right order. And this will take into account the local lighting, as well as the differences in body shape. Besides, it may not be a huge amount of work for the content creators.
    I’m not so sure about normal maps, it sounds more complicated than I can get my poor brain around, but the whole thing seems to me to have a better pay-off than rigged meshes and deformers.

    Like

    1. Re clothing, etc. Just one thing to bear in mind.

      As per my orginal description, anything applied directly to the avatar mesh (skins, system layer clothing, etc.) will not be able to use the new materials processing capabilities in the initial implementation. As you point out, the big benefits with the system go to mesh and prim content.

      Like

Comments are closed.