Category: Content Creation User Group

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, July 27th, 2017 at 13:00 SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live steamed the meeting to You Tube, and his video is embedded at the end of this article. These notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so the provided time stamps may appear to be out of sequence in places. All time stamps are provided as links which will open the video in a separate browser tab, allowing the discussion to be heard in full.

Note: Due to the monthly internal meeting at LL and Vir’s time on vacation, there will only be two CCUG meetings in August: Thursday, August 10th and Thursday, August 31st. Details will be posted on the wiki page.

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures. This may lead to a reduction in the complexity of mesh avatar bodies and heads.

Recent Progress

[1:31-2:01] The project is reaching a point where internal testing at the Lab can begin, allowing the impact of the text increase to be assessed. If this proves successful, the work will start the march towards more general visibility (e.g. availability of a project viewer, probable Aditi testing, etc).

Animated Objects

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation.

• At this point in time, this is not about adding fully functional, avatar-like non-player characters (NPCs) to Second Life
• Animated objects will not (initially):
  • Have an avatar shape associated with them
  • Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
  • Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
  • Use the avatar baking service
  • Be adjustable using the avatar shape sliders
• The project may be extended in the future.
• It will involve both back-end and viewer-side changes, likely to encompass new LSL commands to trigger and stop animations (held in the object’s contents)
• It will most likely include a new flag added to an existing rigged object type in order for the object to be given its own skeleton.

Recent Progress

[2:04-2:20] The focus has remained on getting wire frames and right-click selections to work correctly ((e.g. when you right-click on a mesh, the object stops moving, the correct menu is displayed and the mesh is shown as a selected wire frame). Testing region crossings with animated objects has also started.

[2:21-3:26 and 4:19-4:47] Sitting avatars to animated objects: this has been part of a wider discussion on attaching avatars to animated objects and vice-versa. Vir’s view is that there is no restriction on avatars sitting on animated objects, however, the catch is that the sit point isn’t going to be animated – if it is, and as there is no relationship between the animated object’s skeletal locomotion and the avatar’s locomotion, the two will get out of sync. One suggestion for dealing with this is BUG-100864 “A means of visually rigging a sitter to an animesh skeleton bone”, and Vir indicated that the Lab is thinking along those lines, but it’s unlikely to be in the initial project viewer, when that appears.

[3:33-3:57] Animated objects as avatar attachments: unless there is an unforeseen issue, Vir is hopeful this will be possible. However, it is still awaiting work.

[5:19-5:57] Physics for animated objects: should work the same way as for non-animated objects, although this has yet to be tested.

[7:10-8:43] Scaling animated objects: this will not initially be possible using the avatar shape sliders, as animated objects will not initially have any notion of the avatar shape. However, it will likely be possible as a result of follow-on updates to the initial work.

What Vir is hoping to achieve is a method for reliably scaling an object’s skeleton based on the object’s own scale. That is: you could have three different sizes of an object (baby bear, mama bear and papa bear, say), and the skeleton will scale to whichever model is applied to it, rather than having the mesh default to the size of the skeleton (as is currently the case), which is currently defined by the joint positions.

[8:48-12:33] Shapes and Skeletons: the reason for no body shape support at present is that it makes animated mesh a much more extensive project, requiring the objects have a Current Outfit Folder, which requires them to have a dedicated, avatar-style inventory,  make use of the baking service, and so on. All of this makes for a far more complicated, drawn-out project where the Lab would prefer to develop capabilities incrementally, starting with the provision of the avatar skeleton and then building from there.

This is seen as preferable to trying to incorporate everything people want to see – or believe is required – at a first pass, driving out development over a much longer period and risk developing a feature set the wider creative community in SL doesn’t want. Developing incrementally means features can be built upon and the project as a whole iterated, with deliverables presented in much shorter time frames.

[13:49-15:10] Land impact:  this remains a concern for several reasons (too high, and it could stymie the use of animated objects, too low and it could thump performance for the viewer / simulator). Right now, the Lab has no clear idea of how LI will be calculated for animated objects, and Vir re-states that any LI values provided in the project viewer will be place holders which will be refined as testing and creator feedback  gives more information on what the calculations should be.

[16:45-18:04] LI and scaling: concern was raised that if an animated object does not affect the bounding box, but could be scaled via animation, it could lead to the LI being game. Vir pointed out that scaling via animation is something of a hack, and for scaling with animated mesh, he is referring to the scale of the skeleton being determined by the scale of the model (which would effectively be a “static” scale), rather than having something dynamic. As such, the bounding box should reflect the object size and thus correctly influence LI calculations.

[20:14-24:41] Rigging to attachment Points: rigging to attachment points is being seen by some as the ideal means of animating attachments (e.g. twirling a gun in your hand), due to accuracy involved. Vir’s view is that problems people have encountered in uploading items rigged to attachment points is more of a bug with the LL viewer, and so the behaviour will be allowed (with the possible exception of the newer Bento bones attachment points); there is. however the concern that the ability might lead to attachment points being used as additional free-floating bones.

[37:50-39:36] Animated objects in games: could they be used for interactive elements in games, such as walls which bend when walked into, items which might interact with one another / players, traps which could physically react to an avatar (something wrapping around an avatar, for example). Short answer: yes and no. Yes, these are various interactions that are possible: trees swaying in the breeze, animals and other creature roaming and responding to avatars. No, in that animated objects will not initially have their own physics, so wrapping around an avatar, being used as some kind of clothing, etc.

[39:39-41:58] Will there be limits places on the number of animated objects in a region: there will be limits, but what these will be cannot really be determined until testing can be performed and the Lab can get better metrics on likely performance impacts animated objects have. This could also feed into how the limits are set (e.g. through the LI applied to animated objects, or limiting the number of animated objects which can be attached to an avatar or which can follow an avatar, etc), all of which might be used individually or in some combination(s) depending on the objects in question. Impact viewer-side could also be limited by having attached animated objects impact the avatar’s rendering cost.

[42:00-42:21] Imposters are also likely to be extended to apply to animated objects, although work hasn’t started on this a yet.

Other Items

[0:44-1:21] Bento wiki information: It was mentioned in a previous meeting that some of the Bento wiki content was broken – links weren’t working expected downloads weren’t available. This should now all be fixed.

[25:04-36:15] Development kits for the default mesh avatars: In short, nothing planned on the Lab’s part at present, although due note was taken that there could be potential for such kits and the provision of better starter content for new users to help them in their understanding of what might be possible in SL with content creation.

The idea behind the initial question being to help give those new to mesh content creation the means to better understand what can / cannot be done with mesh in-world, get to grips with some basics of mesh development and modelling. This quickly expanded into discussions on “good” and “bad” content, broadening the availability of of content guides / best practices through to more formalised attempts at education those coming into mesh content creation An argument against this is that it could lead to misunderstands and the creation of poor content in SL, with the suggestion that more extensive best practices guidelines would be better.

[43:20-49:29] Why can’t animators replace default facial expressions in the same way they can replace walk animations? Because AOs affecting walks, sits, etc., all interact with the server-side locomotion graph which has a notion / manages these things. Facial expressions, etc., are not recognised by the locomotion graph, but are enacted viewer-side and the results effectively “passed through” the simulator (which is aware an animation – smile, frown, whatever – is being played, just not what the animation is actually doing).  There is the potential to change this by extending the animation system, but outside of supplemental animation, there is no current commitment to doing this at present.

This discussion extends out into a discussion of the system avatar morph capability and sliders / limitations, which runs through until 53:11.

[54:13-1:03:00] Adjustable walk / run speeds: the ability to adjust / scale walk and run speeds to be in accordance with the size of an avatar, etc., has been a common request (see: feature requests BUG-7006 and SVC-7824 for example). Vir points out that currently, the speeds are set simulator-side and that adjusting them of any on-the-fly changes could be problematic as it involves an array of simulator and viewer changes. As such, scripted capabilities which adjust the viewer-side animation speeds might be an easier solution (Tapple Gao already supplies an AO for avatar creators which allows for some degree of speed control in their products, but something that is more generally usable is seen as ideal).

 

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, July 20th, 2017 at 13:00 SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live steamed the meeting to You Tube, and his video is embedded at the end of this article. These notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so the provided time stamps may appear to be out of sequence in places. All time stamps are provided as links which will open the video in a separate browser tab, allowing the discussion to be heard in full.

Animated Mesh

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation.

• At this point in time, this is not about adding fully functional, avatar-like non-player characters (NPCs) to Second Life
• Animated objects will not (initially):
  • Have an avatar shape associated with them
  • Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
  • Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
  • Use the avatar baking service
• The project may be extended in the future.
• It will involve both back-end and viewer-side changes, likely to encompass new LSL commands to trigger and stop animations (held in the object’s contents)
• It will most likely include a new flag added to an existing rigged object type in order for the object to be given its own skeleton.

Current Status

[3:33- 4:29] Work is focused on getting right-click selections and wire frames to work correctly (e.g. when you right-click on a mesh, the object stops moving, the correct menu is displayed and the mesh is shown as a selected wire frame. All of this seems to be working well, and while Vir is still not in a position to give a time frame estimate of when a project viewer will appear, his feeling is that there are no major obstacles sitting in the way.

[13:24-16:54] Performance impact assessment: The work isn’t sufficiently advanced to carry out any kind of assessment on the impact multiple animated objects may have on simulator and viewer performance. Animated objects should not have as significant a cost as avatars tend to have, but it could get expensive with multiple rigged vertices being animated in a single location.

Vir’s view is that the relevant test will likely be how many joints are actively animated and rigged to, rather than just how many bones are in the scene, given that idle bones aren’t really going to impact anything. Until sress tests can be held and the figures refined, any cost / impact values assigned in a project viewer will be place holders, subject to change.

[43:50-58:00] Attaching animated objects to avatars / rigging prims or non-rigged mesh to skeleton bones:  A discussion encompassing BUG-134018 and attaching animated objects to avatars. Vir sees the problem with the latter as being primarily a performance question / costing issue (large numbers of objects with potentially no land impact be which influence performance).

Attaching avatars to animated objects (outside of sitting on them, as is done with vehicles, etc., currently) is seen as more complicated because the animated object is being controlled by a viewer-side skeleton about which the simulator has no notion, and so ideas of attachment points become vague, and questions open up on how things are tracked by the simulator, given there is no notion of agents associated with animated objects. This discussion also encompasses issues of attaching avatars to bones within animated objects, raising questions of parenting, animation synchronisation etc.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures. This may lead to a reduction in the complexity of mesh avatar bodies and heads.

Current Status

[4:32-4:39] Anchor Linden has been working on other projects recently, but the hope is he’ll be back working on bakes on mesh soon.

[5:40-6:19] Bakes on mesh should allow alphas / transparent textures to be used as they are with the system avatar at present: if an alpha / transparent channel is in a bake, it will place “holes” in the mesh just as they can be used to blank parts of the system avatar. However, once the bakes on mesh project has progressed far enough, this will requiring testing to confirm.

[58:27-58:48] There is no estimate on when a project viewer, etc., for bakes on mesh might appear.

Other Items

Increasing the Build / Mesh Import Size

[6:24-12:18] It was asked if the current upper limit imported objects could be increased so that very large items such as region-sized landscape / terrain models could be imported with having to break them into smaller segments.

There are currently no plans to make any increase in the size of prims / single mesh imports. It’s also unclear how massive objects might be affected by land impact. The latter include things like the overall area of the object, the amount of screen space it might occupy based on its dimensions, etc; so having one large piece of terrain could have an exponentially larger land impact than  using a number of smaller sized pieces to achieve the same result. Additional concerns include the increased risk of encroachment issues, etc., for very large objects.

JIRA feature requests outlining why an increase might be useful and the kind of use cases it could meet are invited.

Maya .ANIM Exporter

[17:39-18:28] Aura Linden continues to work on the .ANIM exporter for Maya (which she has been developing in her own time), and which she plans to make available as a open-source offering. There are also the pre-Bento (translations on mPelvis only) and post-Bento (translations on all bones) .BVH exporters available on the Bento testing page of the wiki.

In Brief

• [18:59-19:42] Various requests were put forward to extend the mesh object physics types which can be specified at upload (e.g. cube, basic havok presets, etc.). Vir requested a JIRA be raised so it could be noted and as / if / when time allows, pain point could be looked at and perhaps improvements / changes to the uploader made.
  • [20:40-22:54] Discussion about a specific issue in uploading a model cat using the official viewer (which crashes) and Firestorm (which manages the upload).
• [25:13-29:26] Discussion (primarily text) on dynamic mirrors STORM-2055 and water as a reflective surface.
• [31:35-34:18] Discussion (primarily text) about BUG-134006 “Viewer code is not aligned to server code when calculating physics shape for thin objects”. This has been accepted by the Lab, but as it is seen as a conflict between the viewer and the server, no decision has been made on whether it should be a server-side or viewer fix. Firestorm have adopted a viewer-side fix, which will appear in the next release. The root of the problem appears to be changes made in the physics costings as a result of mesh being introduced. This is followed by a further conversation on the physics uploader, “custom pivot points, and issues through to 42:14.

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, July 13th, 2017 at 13:00 SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Audio extracts are provided where relevant. Note that this article is organised (as far as possible) by topic, and does not necessarily reflect the chronological order in which items were discussed. Medhue Simoni live steamed the meeting to You Tube, and his video is embedded at the end of this article. Time stamps in the text refer to that recording, and will open the video at the relevant point in a separate browser tab for ease of reference.

Note that the region crashed at around 56 minutes into the meeting.

Animated Objects

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation.

• At this point in time, this is not about adding fully functional, avatar-like non-player characters (NPCs) to Second Life
• Animated objects will not (initially):
  • Have an avatar shape associated with them
  • Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
  • Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
  • Use the avatar baking service
• The project may be extended in the future.
• It will involve both back-end and viewer-side changes, likely to encompass new LSL commands to trigger and stop animations (held in the object’s contents)
• It will most likely include a new flag added to an existing rigged object type in order for the object to be given its own skeleton.

Recent Progress

• [1:50] The issue with current viewers crashing when used on a region where the server-side support for animated mesh has been enabled (due to the viewer receiving unrecognised messages from the simulator) appears to have been resolved.
• Vir is working on ways to get a good match between the object position in-world and the skeleton position, and this will likely be the subject of a future meeting discussion.
• [6:30] As animated objects are set using a flag, any that are modifiable will be switchable as animated or not by users.
• [17:20] There currently isn’t any documentation on animated objects, but hopefully by the time the project viewer appears, information will be made available on what animated objects can do, how they can be used, etc., together with some test files.
• [29:16] There is still no date on when a project viewer is liable to appear.
• [52:58] A reminder that the current project isn’t intended to solve for all potential uses of animated mesh; things like “full” NPCs utilising their own avatar-like inventory for bakes, etc., support of attachment points for non-rigged objects, etc, are seen as more ambitious, and thus follow-ons.

Attaching Avatars and Animated Objects To One Another

[9:34 and 1:02:12] This follows on from the last meeting. No decision has been made on whether or not it will be implemented as an initial part of the animated mesh project, as it involves several complications (such as defining some kind of skeletal hierarchy to differentiate between avatar skeleton and animated object skeleton). Vir’s thinking is perhaps to push to get a project viewer out without any such capability, and use that as a means to generate feedback on what people would like to see and how they think it might work.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures. This may lead to a reduction in the complexity of mesh avatar bodies and heads.

Recent Progress

[2:59]  Anchor linden is continuing to make progress on this work. It seems the update to support 1024×1024 textures is now complete (or pretty much so), as Vir indicated that the next step is performance testing the baking service in handling 1024×1024 bakes.

[5:53] The updated system should allow textures of different sizes (512×512 and 1024×1024) to me mixed and correctly composited, but testing will be required to confirm this.

[7:30] The mechanics of how bakes are to be applied to meshes is still being worked out. Vir’s thinking it will be another editable property which can be used with meshes to determine which face(s) on the mesh use the baked textures.

Supplemental Animations

Project Summary

To provide server-side support for running multiple animations without them clashing (e.g. wings flapping without interfering with walking).

Status

No progress thus far. Once the animated objects project viewer is available, supplemental animations will likely get some attention.

Other Items

Limits

[11:23-21:25]  Removing the 5m bone translation limit: A question was asked about removing the 5m bone translation limit from its origin to allow for really, really large avatars. The belief behind the question being that this was a recent change which now prevents translations greater than 5m where previously they code be encoded and uploaded.

This lead to a lengthy discussion which encapsulated the idea that the limit appears be deeply embedded in the animation system, and has has always been there; disputes on whether or not it was possible using .ANIM files rather than .BVH, suggestions that an earlier version of the .ANIM format (v.0 – although long dead) may have allowed it, etc.

Vir’s stated belief is that the limit is too deeply embedded in the animation system to have ever been different, although he acknowledged that as the Lab has tightened a range of limits to ensure they are properly observed by the system, it is possible that the limit is now being more rigorously enforced. Either way the limit is unlikely to change. It was also pointed out that rotation, joint position, and scaling the mPelvis bone up are all means by which larger avatar models could be produced.

The core voice comments from Vir are below, please refer to the video for the full conversation – which was also partially text-based.

[22:38 and 31:12] Increasing the animation limit: this has previously come up for discussion. Currently, SL should support up to 64 concurrent animation motions playing at one time per agent (e.g. walks, arm swings, wing flaps, tail swishes, etc.). However, how many can be reliably played at any one time without encountering problems might be lower. A request to increase the limit was made on the basis of then allowing LSL-based description of join positions which could be translated into animations, to allow improved scripted locomotion of NPCs.

[+/-35:45 onwards] Pivot point support and improved IK support: There is a largely text-based discussion on pivot point support for mesh and improved Inverse Kinematics (IK) support  / targeting to allow for better interactions between avatars and avatars and objects (e.g. with IK, being able to have avatar hold hands, “grip” a ladder and climb it, etc). Pivot points would allow improved rotations (doors swinging at the hinge, for example) – although it was pointed out that animated mesh could achieve the same goals.

This conversation touches on having custom / arbitrary skeletons in Second Life – although as Medhue Simoni has pointed out, the Bento skeleton already allows for a fairly wide range of “custom” quadruped and biped skeleton forms to be created. As it is, arbitrary skeletons are not something the Lab will be tackling in the near future.

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, July 6th, 2017 at 13:00 SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Audio extracts are provided where relevant. Note that this article is organised (as far as possible) by topic, and does not necessarily reflect the chronological order in which items were discussed. Medhue was a little late to the meeting, and so missed the first 15 minutes. However, his video is embedded at the end of this article, and time steps to it, where applicable, are provided and will open the video at that point in a separate browser tab for ease of reference.

New Starter Avatars

The Lab issued new starter avatars on Wednesday, July 5th. Six out of the eight classic avatars utilised Bento extensions for rideable horses or wings. See my write-up on them for more.

Animated Objects

General Update

Work is continuing on trying to get linksets to work correctly. This is focused on ensuring there is sufficient back-end code to correctly handle multiple animated requests from different elements within an animated object.

Some general questions related to animated mesh were asked at various points in the meeting, these are addressed below.

• Will animated objects use the Bento skeleton – yes.
• [5:07] Will animated mesh allow the return of mesh UUID flipping (removed due to the ability being badly abused) – very unlikely.
• [6:12] Where will animations for animated objects be stored? Within the object (or elements of the object) itself, and called via the object’s own scripts – as per scripted attachments on avatars are handled.
• [7:15] Will animated objects use an AO? Not in the sense of an avatar AO, as animated objects will not make use of the basic system animations / locomotion graph. There was some debate over the effectiveness of using the AO system, although it was pointed out it could make it easier when having pets following you, running when you run, etc. One suggestion was that pathfinding might be adopted to act as a pseudo-AO.
• [29:02] There is still no data on an animated objects project viewer will be available.

Attaching Avatars and Animated Objects To One Another

There is obviously considerable interest in enabling avatars and animated objects attach one to another. For example,  being able to walk up to a free roaming horse and then mount it and ride it, or having a pet running around on the ground you could “pick up” and have it sit on your shoulder, move between your shoulders, look around, lie around your neck, etc.

Achieving this raises numerous issues – how should two skeletal objects attach one to another, how are the independent animation sets handled, how are they kept in sync, how the hierarchy is managed (which is the parent, which is the child, etc.

Some options have been suggested for allowing avatars to attach to animated objects – such by having a specific “sit bone” which could be targeted and then used as an anchor point to help maintain some semblance of synchronisation between the animated object and the avatar’s own animations. Feature request BUG-100864 offers a similar suggestion, utilising a scripted approach. Vir has suggested that this feature request perhaps be used as the basis for further discussion, and welcomes JIRAs on alternative approaches.

“First Pass” at Animated Objects

[09:59] Vir reminded people that the current work is only a first pass at animated objects, designed to provide basic, usable functionality. Providing more NPC-like capabilities: animated objects with locomotion graphs and using the system animations; attaching animated objects to avatars / avatars to animated objects; giving animated objects the notion of an inventory and wearables, etc., are all seen as potential follow-up projects building on the initial capability, rather than attempting to do everything at once.

Caching  / Pre-loading Animations

Sounds and animations can suffer a noticeable delay on a first-time play if they have the be fetched directly at the time they’re needed. For sounds, this can be avoided by using LSL to pre-cache them (e.g. using llPreloadSound) so they are ready for the viewer to play when needed, but there is no similar capability for animations.

A feature request (BUG-7854) was put forward at the end to December 2015, but has not moved beyond Triage. Vir’s view is that pre-loading animations in a manner similar to sounds makes sense, should be relatively straight-forward and could help with syncing animations in general. However, whether or not it might / could be done within the animated objects project is TBD.

Other Items

Sample Code and Code Libraries

[11:39-27:45] Medhue Simoni opens a discussion on code availability – noting that Pathfinding had suites of example code which appear to have vanished, suggesting that the Lab could do more to provide more complex examples of how new capabilities could be used and then made available to everyone could help leverage such capabilities more effectively.

From this came ideas of open-sourcing more of the Lab’s own code for experiences (like Linden Realms), the potential for abuse this could present (people developing cheats for games), the complexities (or otherwise) of LSL coding, the fact that often when the Lab develops something, they’re not aware of exactly what directions creators will take it, and so masses of example code might be of limited value, etc., – although code demonstrating how to do specific things would undoubtedly be of benefit.

Vir points out that the Lab’s resources are finite for coding, and an alternative might be for a more recognised open-source repository to store, reference and obtain documented code and examples might be in order – there are already libraries and resources on the SL wiki, but these aren’t necessarily easy to navigate. There is also the LSL wiki – although this may be in need of update, as well as resources on a number of forums.

[25:47] Within this conversation, the question was asked if the 64Kb limit on scripts could be raised, and the short answer – as Vir doesn’t deal directly with the scripting side of things is – unknown.

[29:56-end] This conversation then spins out into the technical limitations of Second Life (CPU core usage, etc.) when compared to other platforms as seen by one creator. some of the broader comments in voice and text seem predicated on misunderstandings (e.g. the Lab is investing in newer hardware where possible, but are hamstrung by a need to ensure back compatibility with existing content, which sometimes limits just what can be done; the idea that the new starter avatars are No Mod  – they’d fully mod, etc), and which also touches on the basic need for education on content creation (e.g. responsible text sizing and use), before spinning out into general concerns on overall security for content in SL.

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, June 29th, 2017 at 1:00pm SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live streamed the meeting via his You Tube channel, and I’ve embedded the video at the end of this article. Time stamps in the text below reference this video. Note, however, that items are presented by topic, not necessarily in chronological order. Audio extracts are also provided, but please not these may have been comprised to just the core points of discussion / statements (while avoiding any loss of context).

Rigging To Attachment Points

[1:11-8:45] There has been some discussion around this for the last couple of meetings. In essence, rigging to attachment points was used by some content creators in the past to overcome a shortage of bones. With Bento, it was decided that rigging to attachment points should not be supported in new uploads, but would still be allowed for older meshes using it, to avoid content breakage. However, it now turns out that there is a conflict between the simulator (which allows rigging to attachment points) and the viewer (which shouldn’t allow mesh rigged to attachment point to be uploaded – although some TPVs still do, by accident or design).

Vir is still looking into this to determine how best to handle things going forward. However, as it has been pointed out that there is legacy content which cannot be easily updated if uploads of meshes rigged to attachment points is blocked, and clothing cannot be made for mesh bodies using rigged attachment points, His current feeling is that the simulator behaviour will likely not be changed and that the viewer  – based on a JIRA he has raised – will be updated to be consistent with the simulator’s rules, although he made a request that new avatars are not made with meshes rigged to attachment points.

Note: the discussion on the video includes references to Firestorm (version 5.0.1 onwards) no longer accepting uploads for mesh rigged to attachment points due to an accidental breakage (the fix didn’t make the cut for the 5.0.7 release).

Animated Objects

Attachment Points on Animated Objects

[10:29-14:21] Animated objects will have attachment points as they use the avatar skeleton. However, the following should be kept in mind:

• In relation to rigging to attachment points (above) – this should work for animated objects (so this could allow existing avatars rigged to attachment points and volume bones to be converted to animated objects, for example)
• The Lab is undecided on including attachment points at this point in time in order to allow items to be attached to animated objects (or animated objects to one another). They are simply there as a part of the avatar skeleton.

General Status

[39:59-41:30] The animated objects (aka “Animesh”) project is progressing. Still no ETA on a project viewer. Vir is still working on getting the avatar skeleton to work with linksets of multiple meshes making an object.  Most of this is working, although the graphics pipeline still gets upset in places if changing objects from animated to static or vice versa at the wrong time.

Still to be done is evaluating the land impact of animated objects, deciding whether or not to implement support of attachment points now or in the future.

Given that objects already have a land impact, the current thinking is that when converted to animated objects, they will likely incur an addition LI overhead – although what this will be can only be determined in time. Hence, for the project viewer, once available, it may be an arbitrary figure, subject to adjustment.

Bakes on Mesh

[17:28-18:10] Anchor linden is making “good progress” on updating the Baking Service to support increased texture resolutions (512×512 to 1024×1024). Once this work is completed, the next step is to run performance testing on the baking service to assess how well it can support the increased resolution, and whether any additional hardware, etc., might be required in support of the increased loads.

Other Items

“Crazy Bone Scaling Animation”

[9:00-10:05] During the week #25 meeting, a bone scaling animation was demonstrated which could rescale an avatar  to huge proportions, as if it were being “blown up” / inflated. Vir looked at this and believes it is the result of storing animations in a way that’s “not normalised” and which are not being handle correctly for scaling. So while useful in the way it currently performs, the technique isn’t useful for accurately rescaling the avatar skeleton.

Hires Proxy Mesh Rigging

[16:33-16:49] This came out of the last meeting, and Beq Janus is working on a design outline for it, covering how it could supported in-world and protect mesh body creators’ intellectual property at the same time. She plans to offer the document via Google Docs, and those wishing to read it and provide feedback should e-mail her at beq.janus-at-phoenixviewer.com for access.

Mesh Uploader and LOD Options

[20:35-43:00] A suggestion was put forward to change the Level of Detail (LOD) buttons on the mesh uploader from the current “Generate” default to “Load from File” in an attempt to encourage creators to make their own, efficient, LOD files, rather than relying on the auto generation process – which is not always as efficient as custom LOD files.

Feedback was that changing the buttons would not help, but could encourage people simply to generate a single high LOD file and use that (a problem already evident when custom LOD files are used). An alternative suggestion was to remove the ability to adjust the LOD auto-generation process (so no spinners on the uploader) – so unless creators supply their own LOD files, they have to accept whatever the uploader generates for each level.

The core of the discussion in voice is below, but please refer to the video to hear it in full.

This led to a lengthy (primarily text) discussion about how to encourage creators to use their own sensible and custom LODs, which is interspersed with other topics. Some of the idea offered by users at the meeting were:

• Making customer LOD uploads cheaper than if generating them through the uploader
• Offering similar incentives to encourage creators reduce their high-end poly counts and not fudge their low-end LODs
• Improving the preview option in the uploader to better represent LOD sampling
• Adding a field on the marketplace similar to the Land Impact one but for Display Weight on worn meshes (on the basis that a high display weight can be indicative of poor LOD usage), and in theory encourage creators to be more efficient in their use / provision of LOD files
• Have a render meta mode like physics, that shows the quality of the LODs as a colour map (e.g. look at the volumetric relationship between the LODs on the basis that a good LOD should hold volume)
• Instructional videos from Torley – although Medhue Simoni has a 3-part series on LODs: Part 1, Part 2, Part 3.

In Brief

• [14:52-15:36] The link on the SL wiki Rigging Fitted Mesh page to download the avatar skeleton is currently broken.
• [19:04-20:22] Inverse Kinematics via LSL function with global position – this has been suggested a number of times. While noting it would be useful (it might, for example, enable an animation to make it appear as if an avatar is opening a door when standing before it), Vir stated it has not received in-depth thought at the Lab in terms of being implemented or how it would work, given the server currently doesn’t know where the joints in an avatar are, so it introduces a level of complexity as to how things would be handled.
• As most people know, initially accessing Aditi is a case of submitting a support ticket. Inventory is now merged between Agni (the Main grid) and Aditi around 24 hours after initially logging-in to the latter (a merge process is run every day for all accounts which have been logged into since the last run). However, it now appears that changing your SL password can break your Aditi access, requiring a further support ticket.
• [43:09-end] Discussion on copybotting, policies, banning, etc., which threads through to the end of the meeting, and split between Voice and chat.

The majority of the following notes are taken from the Content Creation User Group meeting, held on  Thursday, June 22nd , 2017 at 1:00pm SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Audio extracts are provided within the text, covering the core project LL has in hand. Please note, however, that comments are not necessarily presented in the chronological order in which they were discussed in the meeting, but are ordered by subject matter.

Server Deployments Week 25 – Recap

As always, please refer to the server deployment thread for the latest updates.

• On Tuesday, June 20th, the Main (SLS) channel was updated with a new server maintenance package (#17.06.12.327066), containing fixes to help with the caps (capabilities) router (see here for details).
• On Wednesday, June 21st, the RC channels were updated as follows:
  • BlueSteel and LeTigre should receive the same server maintenance package (#17.06.19.327206) containing internal fixes
  • Magnum should receive a server maintenance package (#17.06.19.327192) intended to fix BUG-100830 (“HTTP_CUSTOM_HEADER no longer works on RC 17.06.13.327111”) and BUG-100831 (“Lelutka Simone bento head spits a script error when attached on 17.06.13.327111 regions (Magnum & Cake)”).

Animated Objects

Vir has been trying to get animated objects using the avatar skeleton to scale in a reasonable way and that linksets are correctly referencing the same skeleton, and things are handled corrected when they are attached or detached. He’d also be interested in hearing from makers of the “current generation” of pets on how they work – how do they maintain ground contact, how they follow along, how the physics is getting managed, so that he can look into trying to make animated mesh objects operate in a compatible manner.

So, if you are a pet maker and can help Vir in this, please either attend the Content Creation User Group meetings, or contact him directly.

Attaching Animated Objects to Avatars and Avatars to Animated Objects

One of the popular aspects of pets today is the ability to attach them to an avatar (so you can carry them, have them sitting on your shoulder, etc), and this is seen as a potentially important aspect of animated mesh. However attempting to do so does present issues, as it would mean linking two avatar skeletons in some manner, something that is not currently possible. While there are some potential ways this could be done, it could add considerable overhead to the existing project, and also brings potential challenges with it – such as ensuring an attached skeleton is correctly oriented, determining the potential performance hit, etc..

Similarly, BUG-100864 suggests a means of going the other way – linking an avatar to an animated object – such as being able to walk up to a free-roaming horse on a region and being able to mount it and ride it, for example. However, this also raises some of the same concerns.

While not ruling either out, Vir is focused on bringing forward a relatively basic means of animating mesh objects using the avatar skeleton, one which can offer a series of potential uses whiles conceivably allowing existing mesh creations (such as pets) to easily be converted to use it. As such, he sees it as a foundation project, which can then be expanded to incorporate other capabilities in the future, rather than trying to pack everything into a single project which could run the risk of very long development times or becoming overly complicated with all it is trying to achieve right from the start.

Baked Textures on Mesh

Work is still focused on the baking service infrastructure updates required to support baking textures on mesh avatars. These are quite extensive, involving changes to the underpinning tools, the servers (including updating Linux), and so on.

Rigging To Attachment Points

There has been some confusion of late as to whether rigging to attachment points is allowed or not. From the Lab’s perspective, it is not allowed for uploaded since the introduction of Bento, but should still work for legacy items. However, what appears to be a server-side glitch in the last couple of weeks seems to have exacerbated the confusion.

Vir’s recommended rule-of-thumb for TPVs to test against the Lab’s official viewer and ensure behaviours match, otherwise confusion could occur down the road once the current glitches have been corrected. To help with matter, he’s going to refresh his mind on what limitations are enforced server-side, and hopefully bring a list of them to the next meeting to help TPVs ensure they are following the requirements in order to avoid future problems.

Other Items

Mesh Body Dev Kits / Clothing Making / “Standardised” Mesh Avatar

This topic took up the core part of the meeting, and as such, the following is an attempt to precis the core points into a readable summary

At the moment, all mesh bodies in Second Life are unique to their creator, utilising their own core shapes and skin weightings, which have a considerable amount of IP bound up in them. Because there is no available “standardised” mesh model available in Second Life, it means that the body creators need to provide developer kits to mesh clothing and attachment makers, which include this core information –  skin weights (in Blend or Maya or DAE or OBJ files) for rigging clothing and the shapes, which potentially makes it very easy for someone to create their own avatar bodies.

To try to reduce this risk, mesh body makers tend to have license agreements clothing makers are required to agree to, and by sometimes limiting who may or may not be deemed eligible to obtain such a kit.   This has  caused some friction / frustration in the cloth making community.

One suggestion put forward to help reduce fears on the part of mesh avatar creators and allow clothing makers more readily support avatar body brands, was that avatar makers should perhaps consider offering only the body shape to clothing makers – and then offer a fee-based rigging service to clothing makers. This would remove the need for avatar makers to give out their skin weight files, offer them a revenue stream and allow clothing makers more equitably create clothing for the more popular mesh bodies.

While there are no projects on the roadmap aimed at the SL avatar system, two other ideas were put forward which Vir agreed, could be worth consideration down the road:

• One is a suggestion that LL look to emulate the ability in Maya and Blender to copy skin weights from an avatar model to an item of mesh clothing by running an algorithm to match the weighting from the avatar to the nearest vertices in the clothing. This would allow the clothing to fit almost any mesh body “automatically”, removing the need for clothing makers to specific weight their clothing to each of the mesh bodies they wish to support.
• The development of a news “SL mesh avatar” designed to operate alongside the existing system avatar (so no content breakage for those preferring to continue using the current system avatar). If this avatar had a sufficient density of vertices, it offers two potential uses:
  • Mesh body makers could use its weightings with their custom shapes to produce individually unique mesh bodies, but which all have a “standardised” set of skin weights, reducing the amount of work involved in creating them (or they could continue to use their own custom skin weights if they wished
  • It could offer clothing makers a single source of skin weights for clothing, simplifying clothing making, which – if combined with the vertices matching algorithm mentioned above – would help ensure the clothing “fits” custom weighted mesh bodies.

The vertices matching algorithm idea might be the more difficult of these two ideas to implement – were either to be considered. However, the development of a mesh avatar that could exist alongside the system avatar could have a lot of merit and help “standardise” the more technical aspects of mesh avatars without impacting their individual shape / look.

Further, as mesh objects can support multiple UV sets, it would be possible for such an avatar to use the legacy UV map use to define the texture spaces on the three parts of the system avatar (thus allowing it to use existing skins, etc), or it could support more “advanced” UV maps (so skin creators could finally design skins with two arms, rather than having the one arm “mirrored” on the avatar, as is currently the case.

Why isn’t Scaling Bones by Animations Allowed?

Scaling bones using animations has never been supported in SL, although Vir isn’t clear on why (and pseudo bone scaling via animations has been possible through attachment point scaling or animating the point positions). However, one of the things that makes designing avatars harder is multiple ways to manipulation and aspect of a bone, because of the potential for conflicts. An example of this is bone translations, which can be affected by both animations and the shape sliders, and so can cause issues.

However, during the Bento project, the advantages of allowing translations through animations was such that the Lab opted to permit it, even allowing for the potential for issues. As scaling bones through animations could bring about a similar level of possible complexity to avatar design (as bones can obviously be scaled via the sliders, this could be the reason scaling bones via animations hasn’t been supported. Currently, this is unlikely to change, if for no other reason it would require a change to the animation format, which currently has no means to interpret bone scaling.