Tag Archives: Mesh

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

Mesh upload patch enhancement for creators

Nalates Urriah drew my attention to a thread on SL Universe regarding the development of a new patch which should be of assistance to mesh creators making rigged mesh items. The patch is by Magus Freston and Gaia Clary, and is designed to solve a particular problem which exists between Collada file formats and Second Life. Magus describes the problem thus:

A limitation of the attachment points in the LL character is that many of them have names with spaces, like “Left Pec”. Collada 1.4 doesn’t handle bone names with spaces as space is used to delimit bone names. So the idea is to replace the spaces with an underscore for the collada file so you get “Left_Pec”, which of course SL doesn’t recognise. The patch just translates “Left_Pec” back to “Left Pec” at import time.

Posting initially to the Machinimatrix blog, where the raw code for the patch can be found, Magus and Gaia devised a test for the patch involving a mesh with two additional spheres which if imported successfully using skin weights, should appear hovering close to the hands and rotating as a result of an added animation.

Mesh uploader test item created by Magus Freston

The test files cane be obtained from the Machinimatrix blog thread, although they require registration / logging-in to the blog in order to see and download them.

Responding to Magus’ request for assistance, Darien Caldwell compiled a version of the Windows SL beta viewer incorporating the patch, and after a couple of bumpy starts, managed to import the mesh successfully and as expected. Since then several content creators have tried the patch and found it works, although a couple of warnings may be thrown up during the upload. The uploaded mesh can be correctly rendered in any mesh-capable viewer.

The test viewer is provided as a ZIP file for windows, not an installer. On unpacking, the contents should save to a default folder (at the time of writing “Test Build 341″ – although you can obviously rename this). Once unpacked, open the folder and double-click on LINDENDEVELOPER.EXE to launch the viewer.

The uploaded mesh, with animation running, showing the expected result: the two spheres orbiting in front of my hands

Related Links

Mesh content creation: morph targets proposal

The Content Creation Improvement Informal User Group has started work on putting together an exploratory proposal for consideration by Linden Lab on the subject of morph targets.

Morph targets (also known as shape targets, per-vertex animation, blend shapes, shape interpolation in some 3D applications) are generally used for complex animations that would otherwise be hard to accomplish with skeletal animation – such as facial animation and avatar customisation. In this latter respect, the SL viewer already uses morph targets to a degree.  The proposal being drafted is aimed at the implementation of a more widespread use of morph targets, for use in such areas as:

  • Complex facial animations on rigged meshes
  • Additional ways for a user to customize the appearance of their avatar
  • Animating the surface of a prim without the need to use a custom skeleton
  • Fine grained control for content creators over how their clothing and avatars deform

Morph targets: animating facial features

It is with regards to this last bullet-point that morph targets are particularly interesting to content creators, as they are seen to have significant potential advantages for clothing deformation than might otherwise be offered by either the parametric deformer, or RedPoly’s alternative approach.

The proposal outlines some of the drawbacks in the latter two approaches, and covers some of the advantages and issues in adopting morph targets. One advantage in using morph targets is that they would allow a content creator to “sculpt” how a morph target should appear, directly within their 3D application of choice, thus giving them the ability to directly control over how a mesh deforms around an avatar (or how a rigged mesh replacement avatar deforms around the base avatar). A potential issue with the approach is that morph targets require additional information to be encoded either within a mesh, or within a texture. This means that additional bandwidth will be required to transmit any mesh which uses morph targets.

Morph targets: a better means of getting mesh clothing to deform?

As it stands, the proposal is in its early phase, although the intention is to complete it and submit it to LL for consideration and feedback as soon as it is felt enough information has been put together. Geenz Spad, co-chair of the CCIIUG, is aware that at the moment, much more input is required in order to get to that stage.

“There could be more input with regards to the content creator’s and the technical perspectives,” he commented to me in discussing the proposal, “The biggest bottleneck is just getting enough input to finish the proposal at this stage.” Of the two perspectives, Geenz feels that it is the technical side of things that is perhaps the more lacking of the two and he would like to see more input from those of a technical mind in terms of potential feature implementation, advantages, disadvantages, possible issues, and so on.

If you are in a position to provide input to the proposal itself, your views would be most welcome, as would your presence at the weekly CCIIUG meetings, which take place every Tuesday, from 15:00SLT at the Hippotropolis Auditorium.

Related Links

Mesh clothing deformation: options

The informal content creation user group is into its 2nd week of meetings. I attended the first, but frequent Viewer crashes meant I lost a huge amount of context during the meeting (particularly as a non-specialist), and didn’t feel entirely comfortable providing a write-up based entirely on the transcript of the meeting. I also missed this week’s meeting due to working on other things.

However, Nalates Urriah provides an overview of the meeting and the core discussion on mesh clothing deformation, which I’m using, together with the meeting transcript, to provide a summary here.

As most people are aware two deformation options have been put forward: the parametric deformer first proposed by Max Graf and which Qarl Fizz has been developing (and versions of which have been made available through an SL Project Viewer), and recently the option presented by RedPoly Inventor.


An early video from Qarl on the parametric deformer

For content creators, both options have certain advantages and disadvantages, and opinion on both has been somewhat split. Of the two, however, the parametric deformer is furthest along in development and potentially offers the more direct means for creators to ensure mesh clothing fits. While RedPoly Inventor’s system offers the advantage of appearing to work with the existing shape sliders, in its current form it will be reliant on alpha layers to a far greater extent, adds complications to the process of weight painting mesh, and would likely require the development of a new set of avatar bones in order to fully work and meet consumer’s expectations.

During this week’s meeting, discussions continued around another “alternative”, that of using morph targets – a special shape that defines how a mesh should deform when a certain parameter is increased or decreased. Morph targets are widely used in 3D modelling and are in fact already employed in Second Life to some extent: they are activated when using the existing appearance sliders, However, in order for them to work in terms of mesh clothing, etc., would require updates to both the viewer and on the server-side and would be dependent upon additional data handling – so further support from Linden Lab would be required in order for this option to mature.

However, it does offer advantages:

  • It is theoretically far more flexible than either the parametric deformer or RedPoly’s proposal
  • It would leave content creators entirely in control as to how a mesh deforms
  • It would probably offer faster rendering than Qarl’s deformer
  • Morph targets might be used for animating mesh avatar facial features

For those interested in the more technical discussion on morph targets and SL, the transcript of the meeting is the place to visit, covering as it does such diverse aspects as LSL support for the approach, working with avatar physics and so on. In particular, there is detailed discussion on what needs to be put into any proposal relating to the use of morph targets that could be put to LL – a discussion liable to continue in next week’s meeting.

As Nalates points out in her article, there was also discussion on how to move things forward vis-a-vis Qarl’s deformer – Qarl has previously indicated via Metareality that he is more-or-less waiting for a consensus from “the community” (although it is doubtful any consensus can be reached without LL having a cast of the dice). This also involved debate as to whether things have to be an either / or solution, or whether things could move forward on more than one front.

To this end, Nalates has set-up a poll on her blog. If you understand all of the issues involved on the situation, and have a clear opinion on what you would like to see, please take a minute to complete the poll.