When mesh content was being introduced to Second Life, linden Lab implemented a “gate” on people’s ability to upload mesh models to both Agni (the Main grid) and Aditi (the Beta grid).
In both cases, anyone wishing to upload mesh had to:
Provide payment information to Linden Lab
Complete a mesh intellectual property rights tutorial / questionnaire.
This has now been streamlined so that all someone who wishes to upload mesh needs to do is
Provide payment information to Linden Lab
Confirm they have read / agree to Linden Lab’s Terms of Service and Intellectual Property Policy, and acknowledge they may be subject to Linden Lab’s removal procedures should you fail to comply with these policies.
For those already “cleared” to upload mesh to Second Life, nothing changes – you remain approved.
However, if you are new to uploading mesh models to SL, you now have a far more streamlined process to complete in order to do so, as noted below.
Go to your dashboard at secondlife.com, and select Mesh Upload Status from the left-hand Account menu. This will display a summary page of your current status. If you have previously provided payment information to linden Lab and previously completed the Mesh Upload Tutorial, your information will be shown in green (below).
If you are registered for uploading mesh, both parts of the Mesh Upload status page will be shown in green
If you have not provided payment information to Linden Lab (only required for uploads to the Main grid) and / or you have not confirmed you have read the Terms of Service (ToS) / the Intellectual Property Policy, one or both of the status boxes on the page will be red.
Further, note that you cannot confirm acceptance of the ToS / the Intellectual Property Policy until you have provided payment information, as shown in the image below (note the second red box).
The Mesh Upload status page for someone who has not provided payment information to Linden Lab. Note they cannot accept the Terms of Service / Intellectual Property Policy until they have.
If payment information needs to be filed, clicking the My Payment Info will display your account’s Billing Information Page, where you can add a payment method. When you have done so, you can return to the Mesh Upload Page, which will show the payment information section in green, indicating your payment method is on file.
You can now proceed with accepting the terms and policy, by clicking on the Accept The IP Terms link.
The Mesh Upload status page for someone who has provided payment information, but who has not confirmed they have read the ToS / Intellectual Property Policy
Doing so will display the Accept IP Terms page, which has a large I Accept button, and links to the ToS and the Intellectual Property Policy. note that both of these will open in the same browser tab as used by the Accept IP Terms page, so use your browser’s Back button to return to it when you are ready to accept.
When you are ready to do so, click the I Accept button to confirm your agreement to adhere to the ToS / Intellectual Property Policy. The Mesh Upload status page will update to show the required fields are green, and you are cleared to start uploading mesh models via the viewer.
Again, if you were already able to upload mesh to Second Life, nothing has changed. You do not need to re-affirm your ability to do so. The reason for this change, so far as I can tell, is because the tutorial / questionnaire was seen as a little cumbersome and top-heavy.
With thanks to Whirly Fizzle for the nudge for me to take a look.
I’m prefacing this article by saying I’m not a fashion blogger, nor am I particularly fashion-oriented SL purchaser. So this piece isn’t an examination of “Liquid Mesh” clothing from a fashion / fit standpoint. Nor is it intended to be an in-depth technical examination of the technique and how it deforms, its pros and cons, creation issues, etc. It is simply intended to offer up general information on what the technique is, what the concerns are, and how people might best determine whether it is an option for them.
A Little Bit o’ History
When the capability to support mesh within SL was first being developed, that it could be used to create clothing etc., didn’t appear to factor into the Lab’s thinking, and so how such items might be made to fit avatar shapes properly wasn’t of major concern to them. However, during the Mesh Closed Beta, a method was proposed whereby wearables could be weighed to the avatar’s collision volumes, a technique which, if used, would allow them to deform somewhat to the avatar’s shape.
AshaSekayi Ra notes that at the time, Prep Linden requested clothing samples weighted using the technique be passed on to him so that the Lab could take a look at the idea. However, she didn’t hear anything further on the subject, despite supplying samples herself. Asha also thinks that Prep may have heard of the technique as a result of a conversation with RedPoly Inventor.
Collision volumes are essentially a simplified version of the avatar form primarily used to between your avatar and other avatars / objects. As Gaia Clary recently explained, they give a rough approximation of an avatar’s shape and they can be adjusted via the Edit Shape sliders. So, clothing items weighted to them can be adjusted somewhat in line with the avatar’s shape.
That said, there are limitations. For one thing, there are only 19 collision volumes; and this limits how and where they can be weighted by default, and how well clothing using them can deform with changes to the avatar’s shape. For example, there is no collision volume for breasts, so clothing using the technique won’t deform to breasts or breast size changes.
In June 2012, RedPoly Inventor again drew attention to the idea during a Content Creator’s meeting, releasing a video of the technique, as well as a demonstrator dress.
By his own admission, the solution was not perfect due to the lack of suitable weighting points in the collision volumes, as noted above. To overcome this, he suggested the development of addition “bones” (weighting points), which he called “cbones”. However, given there is generally little appetite within the Lab to tinker around with the avatar to any great extent, it was unlikely this latter idea was going to be taken-up, and after a while the use of collision volumes for mesh weighting / deformation seemed to quietly slip away.
Moving Forward
Since then we’ve had yet more delays with the development and release of the mesh deformer for a wide variety of reasons. That no official deformer has appeared has seen a number of content creators producing mesh wearables which use collision volumes for weightings / deformation in a manner similar to that demonstrated by RedPoly Inventor. Perhaps the first on the scene was Redgrave, back in late 2012, with their Liquid Mesh range (the name which is now synonymous with the technique), with others such as Egoisme and Bax also producing their own items as well. As such, the debate around the approach has been ebbing and flowing for a while, and has recently seen renewed discussion.
The system isn’t perfect, as noted above; the need for alpha layers isn’t necessarily eliminated for example, and because collision volumes are only a rough approximation to the avatar shape, problems can still be encountered when making shape changes even where the two do align. But even with the potential shortfalls, the fact remains that in many cases, this method can result in clothing items which do fit an avatar’s shape more reasonably than by purely relying on a set of “standard sizes”, as Strawberry Singh demonstrated in a recent video which accompanied a blog post on the subject.
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. This includes:
More correct sorting when streaming objects to viewer
More objects are categorised as cacheable by the server (improves scene loading speed when revisiting regions)
Packed full ObjectUpdate data recycled for multiple viewers (optimisation of how UDP packets are built)
Additionally, the package includes 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).
As always, there are release notes for the deployment.
Following deployment, there have been assorted reports that:
Region crossings in vehicles are generally a lot better – although the BUG-1814 fix will not reach the entire grid until after the RC deployments for Wednesday 3rd April (see below). However, feedback is pretty much in line with my own Magnum tests in my Mark XI Spitfire
There are reports that the fix for BUG-1779 is not working in all cases – Whirly Fizzle reports that her Meeroos are still suffering the same update issue as prior to the roll-out
There are also reports of increased issues with prims / parts of linksets failing to rez until right-clicked upon – although there is some speculation that this might be worse for some TPVs as they may not have recent code updates from the Lab.
Prims failing to rez until right-clicked: issue more prevalent?
Release Candidate Channels
On Wednesday April 3rd, the Release Candidate (RC) channels should receive the following updates:
BlueSteel and LeTigre should receive the same package as week 13, which includes the new Animation Override LSL capabilities. In addition they also should receive:
The changes deployed to the Main channel on Tuesday April 2nd
A fix for BUG-2134 – “Avatar pre-jump is sporadic”
Magnum should receive Monty Linden’s new server-side HTTP updates (see below) – release notes.
SL Viewer
The Mesh Deformer project viewer was finally updated on Tuesday March 2nd with the release of version 3.5.1.273384. There are no changes to the deformer with the release – which does see the deformer code now merged with the CHUI codebase.
HTTP Updates
Monty Linden’s HTTP updates should arrive on the Magnum RC on Wednesday 3rd April, assuming no last-minute hitches
The next stage in Monty Linden’s HTTP project should reach the Magnum RC channel on Wednesday April 2nd. these updates can be briefly summarised as:
More complete and more correct headers on texture and mesh fetches – these should ensure the viewer is better able to handle objects as they are downloaded to it
Keepalive connections for some HTTP-based services
Notes on the latter point explain that:
The behavioral change for HTTP connections marks the beginning of support for persistent (keepalive) connections. Services transiting the capabilities router, at ports 12043 and 12046, may honour a request for keepalives and keep a connection open after request completion. These services may include such activities as texture and mesh fetching, event delivery to viewer, HTTP-In for LSL scripts, asset uploads and inventory operations. Benefits from keepalives include immediate and future throughput increases and less TCP connection churn (which often disrupts consumer-grade networking equipment). The exact set of services that will see this is expected to change over time.
In other words, connectivity between the viewer and the server should be somewhat more robust and, in the case of older router models, less taxing.
Server-side Baking Avatar Z-offset
I missed the Monday Content Creation meeting on April 1st due to family commitments. However, I understand from information received that the question of avatar height offsets. The solution, as currently offered by LL, is considered to be less than optimal for all situations. In replying to the question, Nyx Linden apparently indicated that the Lab do not consider the matter fix in light of further examples having been given, and that further work in correcting matters is in-hand. Whether these further fixes address all concerns remains to be seen.
Other Items
Griefing
Griefing was once again a subject of discussion at the Simulator User Group meeting on the 2nd April. As with the last time the recent increase in mainland griefing was raised, LL are not willing to discuss specifics in terms of what they’re aiming to do. However, Simon Linden did provide more general feedback in response to questions.
Nothing new to report about griefing tools … but it is on our radar and definitely a concern … When looking at griefing problems the most serious issues and the ones that get the fastest attention is anything that can crash a region or viewer. After that there’s a broad spectrum mostly based on the level of pain and if there are things that can or can’t be done about it already. The fight has been going on since long before I joined the Lab.
During the discussion, Simon was at pains to again point out that those Lindens attending the User Group meetings are not responsible for dealing directly with griefing accounts – that is the role of the Governance team. However, he also made it clear that there are internal LL meetings where griefing is discussed, saying:
The Lindens that come here like Andrew, Kelly and myself are server developers, so we focus on features there that can help. Dealing with accounts is outside our area and the Governance people handle that … We do regularly meet and discuss what’s going on … everyone is aware of the recent increase in griefing … It’s gotten a lot worse recently. Not due to technical failures and it becoming easier, but from more griefers.
Simon also indicated that the bug which allowed objects to get stuck in limbo at the edge of a region, where they could be exploited by griefers, now has a fix in the BlueSteel and LeTigre RC channels, and that measures to help combat particle spamming are “in the pipeline”, with the hope that a project viewer will be featuring these will be available soon.
SCR-19 – Script function to return objects remains a popular choice of handling griefing objects, and Simon – purely as a brainstorming exercise asked for feedback on region controls which could be turned off / options which could help make land more “griefer-proof”. Some of the responses included:
Having particles require group permissions
Banning individuals based on their group membership. This raised questions over privacy and usefulness / effectiveness. The former as it would require a means to discover someone’s groups, even if hidden; the latter points because it would only otherwise work on a person’s active group, it would be relatively easy to circumvent (by leaving the group, if necessary)
Blocking object rezzing based on the creator’s name
Turning off public script operation over explicit banned/no access parcels, making the return time for public rezzed objects over explicit banned/no access parcels 1 minute.
Again, none of this should be taken as an indication that any of the above will be explicitly developed by LL; rather they are likely to be added to the melting-pot at the Lab and help LL better understand where user concerns lay and what directions they should consider for further technical responses to griefing issues.
Mesh Object Physics Shape
There has been a (possibly long-standing) problem with the physics shape for some mesh objects being changed unexpectedly. Lares Carter, speaking at the Simulator User Group, described it thus:
The physics shape type for mesh objects gets changed from Prim to Convex and doesn’t change back until the object is right-clicked. This only happens for linksets that contain a prim with a target omega property. Things that can trigger the change: movement changes and rezzing the object. There also seem to be other factors as it can happen for static objects too.
The issue has been reported in BUG-2147, and differs from the problem wherein some objects / parts of builds (such as floors, walls, etc.) fail to rez until clicked upon (but can be walked on, etc.), in that the mesh object can be seen and can collided with – but the physics shape is incorrect. There are reports that analysing the physics model in the mesh uploader can be used by content creators to mitigate the issue. However, this issue is now on the Lab’s radar in terms of further investigation.
Deployments this week are being delayed some 24 hours, which means the main channel deployment will not take place until Wednesday 31st October, and the RX channels on Thursday November 1st. This has led to concerns that the main channel deployment / restarts may impact any Halloween events taking place across the grid on Wednesday 31st. Simon Linden promised to raise the concerns at an internal LL meeting taking place later on the 30th October, however, at the time of writing, the Grid Status page reports that the deployment will go ahead, starting at 05:00 SLT on the 31st.
In the meantime, the deployments for the week remain largely as previously indicated:
The main channel should receive the code currently on BlueSteel and Magnum. As mentioned above, the code has no externally visible changes but has some system level adjustments – release notes
LeTigre will receive a further update for the code currently running on it, which will include a number of bug fixes and pathfinding updates – release notes
On Friday 26th October, Simon Linden indicated to me that Magnum should be receiving the code planned for week 43 (the llSensor() problem has been fixed) which will include Baker Linden’s Group Services code currently on Snack, however, as of the Simulator User Group meeting on the 30th October, the final release notes for Magnum had yet to be published, so the update may still be in a state of flux
BlueSteel should get the same code as is on LeTigre.
Interest List
Andrew Linden has fixed a bug wherein some child prims in linkset fail to rez and he has carried out further work on performance issue he reported last time. This turned out to be an issue with the code which caused the simulator to send a full update of everything within view to the viewer each time an avatar within visual range moved. Understandably, on crowded regions, this led to performance issues.
The code is in the process of being revised to ensure it only calls for “terse” updates to be sent to the viewer, which will help ensure more relevant information is sent to viewers when updating, which should reduce the performance hits.
Group Services
Baker Linden, speaking at the Simulator User Group on Tuesday 29th October, said that the server-side code for this project, which should improve the load times and editing abilities for very large group lists, seems to be working “moderately well” since the deployment to the Snack RC channel last week. However, some bugs have been found, Commenting on these, Baker explained that, “The group name, description, and other things don’t load right now on the Snack RCs.” However, the bugs have been investigated and fixes found, which should be merged into the code ahead of the planned deployments on Thursday November 1st. The fixes have also been tested on Aditi, where they’ve been found to induce a slight lag on group loading.
For the time being, testing this now code continues to require a dedicated SL project viewer (available for Windows, Mac and Linux), until such time as issues with the SL beta viewer code can be fixed and merges with viewer project code resumed / made available to TPV for integration.
Avatar Baking
Work is still progressing, Nyx Linden confirmed, talking at the content Creation User Group on Monday 28th October. How far down the road the work is, is unclear. The server-side of things will apparently be using the code being developed for the viewer, and it is this which is the focus of attention for the present, as has been the case for some time.In talking to TPV developers on the subject the last time the matter came up, Oz Linden confirmed LL’s plan is still to give TPVs “at least” 2 months (eight weeks) notice prior to anything being rolled out for testing, in order to give TPVs sufficient time to incorporate the code into project viewers of their own and assist with the overall testing.
SL Issues
Mesh Alpha Issue
Theresa Tennyson demonstrates the skinned mesh / alpha issue
Also during the Content Creation meeting, a problem with alpha textures as applied to worn skinned meshes was brought up. Theresa Tennyson demonstrated the issue during the meeting, which somewhat resembles the old invisiprim / alpha issue.
Siana Gearz suggested two possible causes for the issue, “[The] first is that rigged mesh transparent surfaces appear to be drawn before prim transparent surfaces. [The] second issue is that the shader apparently writes depth for whole fragment, not just for relatively in transparent pixels.”
Nyx Linden requested a JIRA item be raised for the issue, again highlighting the problem with the recent JIRA changes, in that outside of those with access privileges to the new system, no-one could actually confirm if a JIRA had already been raised.
ETA 31st October: Seems a public JIRA on the matter is available – see MartinRJ’s comments which follow this article. Many thanks, Martin!
With thanks to Theresa Tennyson for the Simulator UG meeting transcript
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
Machinimatrix forum post from Magus and Gaia (including test .DAE file and animation file attachments)
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.
Inara Pey: Living in a Modemworld 