2018 SL project updates 3/2: Content Creation User Group

A rally of (Animesh) raptors on Aditi

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 18th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

There is no video for this meeting, as Medhue missed the first 30-ish minutes. Audio extracts are supplied instead, where relevant.

Animesh (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. It involves both viewer and server-side changes.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.
  • Will not support its own attachments in the initial release.

Note that the focus of this project is not currently about providing fully functional NPCs at this point in time, which is seen as a follow-on project.

Resources

Viewer Update

The Animesh project viewer updated on Thursday, January 18th to version 5.1.1.511908. This includes a merge up to the Alex Ivy viewer code base, and so is only available for Windows (32-bit and 64-bit) and Mac OS X (64.bit). A number of updates are also included with the viewer:

  • Reduced lag when zooming in and out on some models.
  • Improved rendering performance when preview wireframes are displayed.
  • Some diagnostic updates and performance fixes.
  • In mesh upload, allow underscores in joint names to substitute for spaces.

Performance Profiling / Animesh Limits

As promised in the week #2 meeting, a region has been set-up on Aditi for public Animesh performance profiling which has a tri cap that can be varied (called Animesh XL), allowing it to be set higher than the 50K limit found on the other Animesh regions on Aditi. The Lab has internal regions set-up for performance profiling as well.

There has been a request for a triangle count and/or skeleton count per square metre limit, rather than the triangle count and land impact limits the Lab are currently experimenting with. Vir concedes that this may give a similar result to the Lab’s approach with tri count and LI, but also notes that people are already pushing tri counts to the limit, and he’d rather have something that helps push towards more optimised content creation. He also notes that tri count isn’t the only potential performance impact  – texture use, for example can also have an impact – so it’s a case of finding the right balance and ensuring that balance uses figures which are easy for creators / users to grasp.

The tri count limit is per object / linkset for Animesh, and is something of an approximation based data specifying the size of an object, in order to avoid having the simulator having to carry out all the triangle count calculations (and possibly impacting simulator performance). The resultant figure does under-estimate of the actual number of triangles within an object / linkset – but not, Vir believes, by a huge amount.

One issue around performance is avatar attachments, which don’t directly count towards region limits in the same way as things like LI, but which can still have an impact on performance (as can be seen with avatars wearing a lot of high-poly mesh attachments). However, re-working how attachments are handled specifically for Animesh is considered problematic, and unlikely to be re-worked (and so is being handled by a straightforward cap on how many Animesh attachments can be worn at one time – initially 1 for testing purposes).

Animation Playback Issues

It’s been noted that animations already running on an Animesh object don’t necessarily play for those entering the region where they are running, or update correctly when camming to them for the first time. This appears to be a race condition, with the viewer receiving information on the animation before it has rendered the object being animated, resulting in the animation being ignored. Vir is confident that now the cause has been found, the issue can be fixed.

There is also an issue related to the Interest List where an Animesh object in a neighbouring region fails to update (animate), even when in your field of view and draw distance.

Both of these issues are still being investigated.

There is a claim that animations fail to play when an Animesh object is attached directly from inventory. This is something that isn’t being seen by the Lab, and which might be down to code within the animation script itself, or could be an issue. Vir has requested a JIRA specifying the problem and how to reproduce it.

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, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

  • The current work to update the baking service to support 1024×1024 textures.
  • An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

Vir believes Anchor Linden has resolved the issues around getting the appearance service updates out.

Other Items

Screen Release Estate and Multiple Monitors

The Second Life viewer is constrained to the window / screen on which it is being used: however many floaters and panels a user opens, they can only be displayed in the one window / screen, which can quickly become crowded. This had led to various suggestions on how the issue of screen real estate use might be improved, including:

  • Making floaters and panels so they can be displayed outside of the main viewer window. Firestorm actually developed a proof-of-concept model for this several years ago. However, it was just an experiment, and the overall functionality was limited. The idea was thrown open to allow viewer developers to work on the idea, but the complexity of the work meant it was never carried forward.
  • Altering Second Life so that more than one viewer session can be run from the same account at the same time: the idea here being that a use with multiple monitors could log into SL with their account, position the viewer on one screen, then log in again with the same account, and have that viewer instance on a second monitor – so they could use one for all their chat and inventory floaters, while have a clear in-world view on the other. This would require extensive changes to the back-end of SL, and so is potentially even more complicated than making the viewer floaters work outside of the main viewer window.

Next CCUG Meeting

Due to various conflicts, it appears that the next CCUG meeting will not be until Thursday, February 16th, 2018. However, as this has yet to be confirmed, the best thing for the next 2-3 weeks is to monitor the CCUG wiki page for updates and meeting notifications.

Advertisements

2018 SL project updates 2/2: Content Creation User Group

Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 11th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. 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, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.

Animesh (Animated Mesh)

I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!

– Vir Linden joking about the name “Animesh”.

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. It involves both viewer and server-side changes.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.
  • Will not support its own attachments in the initial release.

Note that the focus of this project is not currently about providing fully functional NPCs at this point in time, which is seen as a follow-on project.

Resources

Performance Profiling

[2:08-3:58] Work is now starting on performance profiling for Animesh to determine suitable limits (e.g. tri counts, LI, etc.) when Animesh goes live. This is regarded as being one of the last steps before the project moves to the main grid. As a part of this, Vir has been adding the ability to control the triangle count limits for Animesh objects on a per region basis. This will be used to set different limits on different regions for the Lab’s internal performance profiling, and a region with the capability will also be made available on Aditi for public testing, and details will be made available once the region is up and running.

Object Animations And Animating Animesh

[43:13-55:34] A convoluted enquiry requiring a feature request in order to be made clear, but appears to be a request to provide a means for object animations to override an Animesh object’s own animations. So, for example, an Animesh hamster could be placed into a treadmill, and the treadmill either override the hamster’s in-built animations (stored in the hamster object’s Contents tab of the build floater) and cause the hamster to run, in much the same way as in-world objects can override avatar animations.

Such a capability could offer additional flexibility for Animesh – if a creator brings out a new toy for a pet (e.g. the treadmill, above), a means by which the treadmill could override the pet’s behaviour would avoid the need to update the pet as well in order for it to make use of the new toy. It’s unlikely such a capability will be considered for this phase of Animesh; however, Vir has requested a feature request on the idea is filed, so it can be considered alongside other work in a future Animesh update.  Hopefully, any feature request will avoid the use of pseudo technical terms such as “faux permission system” and “reverse animation system”, which initially caused some confusion when the idea was raised at the meeting.

In Brief

  • [4:00-8:10] Performance (FPS) issues when camming on Animesh: there has been a report of some mesh items causing drops in FPS rates when converted to Animesh, leading to choppy camera motion for some. Vir has been looking at one of the models in question, and believes the problem lies with the recalculation of attachment overrides, which can be excessive and even be carried out when there is no change in the object itself. Improving when and how the calculations are handled should hopefully resolve the problem, which can obviously be exacerbated through models having more joint positions defined. The fix, once implemented – hopefully in the next Animesh viewer – may help with other instances where there is a performance drop-offs when camming / zooming.
  • [8:51-10:55] LOD Drop: this is not considered an Animesh specific issue. Essentially, Animesh objects are being treated by the viewer as if they are avatars, and so get a similar boost in LODs, which needs to be tweaked.
  • [31:02-33:29] “Dropping” Animesh objects (i.e. allowing avatar to put pets, etc., down on the ground, without having to detach them back to inventory first, then rez them in-world): as per my 2018 week #1 CCUG meeting notes, this is still considered too big a piece of work to add to the Animesh project, as it requires changes to a variety of elements: land impact calculations, physics updates, etc. It could also result in forcing users to re-log should a No Copy pet be dropped and fail to rez in-world, in order for it to correctly register in their inventory again. However, such a capability for dropping mesh might be looked at again in the future.

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, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

  • The current work to update the baking service to support 1024×1024 textures.
  • An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

[8:21-9:25] Anchor Linden is working on issues around getting the appearance service updates out. These include on problems specific to Animesh attachments. A setting is also being added which means that the texture resolution increase (to 1024×1024) isn’t applied by the baking service until there is a mesh surface requiring it. Work on adding further baking servers is also required to manage the compositing / baking load at 1024×1024. However, the updates are now available on Aditi.

[11:04-21:12] A further explanation as to what Bakes on Mesh is, born from expressed confusion over the term “baking” in terms of 3D rendering, and the fact that the current work only applies to meshes worn by avatars.

[21:22-26:00] Bakes on mesh for Animesh: this would be part of any “phase 2” work that follows-on from the initial work on Animesh, once Animesh objects have a formal inventory structure. This would be required in order for the baking service to be able to recognise and use textures with Animesh objects. Includes a discussion on how the baking service currently works.

Other Items

[1:14-2:03] Mesh uploads: recognising linkset object names: as mentioned in my previous update, when uploading mesh objects, only the name of the root item in a linkset is recognised, everything else is simply “object”, rather than carrying over any naming convention used when creating a model (e.g. “dog”, “dog_head”, “dog nose”, “dog_tail”, etc., or some variation of more useful naming). Various requests have been made to change this for consistency of item naming. The Lab has been looking into this, and a problem is that the server itself ignores any linkset object names outside of the root object. This means that preserving object names is more complex than had been hoped, although investigations on what might be done are ongoing.

[38:08-39:20] *JOKE**: comments on mirrors and raytacing: do not take seriously! An explanation is supplied.

2018 SL project updates 1/2: Content Creation User Group

A rally of (Animesh) raptors on Aditi

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 4th, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. 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, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.

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. It involves both viewer and server-side changes.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.
  • Will not support its own attachments in the initial release.

Note that the focus of this project is not currently about providing fully functional NPCs at this point in time, which is seen as a follow-on project.

Resources

General Project Status and “Must Dos” List

[33:24-34:10] There are around 14 “must do” items remaining on the list of work to be completed for Animesh before it can really move towards release. Some of these are fairly major – such as performance profiling (tri, count, LI, etc., limits evaluation, and so forth). There are also a number of bugs to be fixed or determined to be trivial enough so as not to prevent Animesh from moving to release / require work outside of Animesh.

Bug Stomping

[1:12-1:54] Animation Playback issues: as highlighted at the December 14th meeting, animations already running on an Animesh object don’t necessarily play for those entering the region where they are running, or update correctly when camming to them for the first time. It now appears this is a race condition issue, with the viewer receiving information on the animation before it has rendered the object being animated, resulting in the animation being ignored. Vir is confident that now the cause has been found, the issue can be fixed.

Shadow Rendering Issue

Animesh could exacerbate an issue with rendering shadows for faces of rigged / static mesh using transparencies

[3:33-13:52] There has been a long-standing issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by the latter to render incorrectly (shadow rendering conforms only to the geometry silhouette). Animesh can exacerbate this issue on some objects (note the image of the tree on the right, and how the shadows of the leaves (faces using transparencies) are render.

As this appears to be a rendering pipe issue, rather than a specific problem with Animesh, it may require investigation and resolution by those handling viewer rendering pipe issues, If so, this could take time to complete, and so is currently being viewed as outside of the current Animesh project, and not a blocker to any initial deployment of this phase of the Animesh work.

“Dropping” Animesh / Mesh

[43:12-47:25] As previously noted in these updates, worn mesh cannot be simply “dropped” in-world. It has to be detached to inventory and then rezzed in-world from there. This makes the ability for people to pick up Animesh pets, carry them, then put them down in-world awkward.

The Lab’s view is that as dropping mesh directly in-world was never considered, the code-path for achieving this is not clear, touching as it would on a variety of elements: land impact calculations, physics updates, etc; there’s also a risk of forcing users to re-log should a No Copy pet be dropped and fail to rez in-world, in order for it to correctly register in their inventory again.

However, pets are seen a major use for Animesh, so not having a means by which they can easily be put back down in-world after being carried is seen as a potential limitation in the adoption of Animesh by pet creators; as it is, many have kept to using (render-intensive) sculpties with their pets, simply so they can retain the ability to pick them up and then put them back down in-world, rather than having to force users to detach and re-rez the pet after holding it.

The issue is again being that back to the Lab for further discussion.

In Brief

  • [14:49-17:12] Global scaling and resizing: not something that is going to be implemented for Animesh with this initial work, but may be added later. It is possible to get the effect of global scaling on a rigged object by scaling in joint in the hierarchy individually, but this may not give consistent, expected behaviour.
  • [17:32-20:29] Setting position and rotation of rigged meshes: slight confused discussion on whether rigged mesh attachments can be re-positioned / rotated. Generally, rigged meshes cannot be re-positioned / rotated as their the vertices are recorded to set distances from the avatar bone. However, Animesh attachments (which have their own skeleton) should be capable of position / rotation changes releative to their attachment points.
  • [20:44-24:40] Slider support for Animesh: avatar shape sliders are not supported in the initial Animesh work, as these require a shape to be associated with an object which, as per the summary notes for the project (above), is considered a possible Animesh follow-on project. For this phase of the work, shape changes can only be defined by setting joint positions / using animations. The reason why shapes, sliders, etc., are seen as a potential follow-on project is that they will require an extensive overhaul of the baking service (which manages appearance information), so that it recognises Animesh objects and can handle them.

Continue reading “2018 SL project updates 1/2: Content Creation User Group”

SL project updates 51/2: CCUG and viewer

Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, December 21st, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. 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, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. However, the first part of the meeting is absent the video, so I’ve included two audio extracts of salient points raised, taken from my own audio recording of the meeting. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.

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. It involves both viewer and server-side changes.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.
  • Will not support its own attachments in the initial release.

Note that the focus of this project is not currently about providing fully functional NPCs at this point in time, which is seen as a follow-on project.

Resources

Bug Stomping

  • Animation Playback issues: as highlighted at the December 14th meeting, animations already running on an Animesh object don’t necessarily play for those entering the region where they are running, or update correctly when camming to them for the first time. This had been considered a viewer issue, but could equally be a simulator / viewer race condition wherein the viewer is receiving animation information before it knows what to do with it (and so is ignoring it). Vir is still looking into this.
  • Object Selection issues: this isn’t just an Animesh issue per se. Historically, selecting multiple animated objects (or an avatar) so they are displayed as wire frames has been handled “extremely inefficiently”, impacting local frame rates. A fix is in hand for this, and will be in the next update of the Animesh project viewer.

Animesh Release ETA and Limits

There is still no indication of a release date for Animesh. Work still to be completed / carried out includes:

  • Bug fixing, including the two issues noted above.
  • Performance profiling (tri, count, LI, etc., limits evaluation, etc.).
    • It is worth repeating (again) that the current limits of tri count, LI, and number of attachments are purely for the purposes of performance testing, they are not the “final” limits for Animesh, some of which will hopefully be somewhat more relaxed / reflective of server / viewer capabilities when scaling Animesh use within a region.

The initial tri count limit (again, set for testing purposes only) was increased from 20K to 50K with the current project viewer release (version 5.0.10.330058, at the time of writing). As noted in my week #50 update, this increase had been requested for some time – although it appeared to be wanted more for testing proposed Animesh products, rather than testing the basic Animesh capabilities. Zooby’s has since issued a video of one such new product, involving both a wearable cat avatar, and which is also intended to support the avatar being used as an in-world Animesh object, once Animesh is released.

Animesh Use Cases

The focus for Animesh among creators thus far has been for avatars (NPCs), and creatures, pets and things like mechanoids (both free-roaming and wearable). However, there is potential for Animesh to be used for landscaping as well: tree boughs / grass moving in the wind, water features, etc., and the Lab is interested in discovering how much appetite there is among creators to use Animesh in this way, particularly when it comes to profiling performance and limits.

Skeleton Use and Bone Naming Convention / Parenting

An extensive discussion on using the skeleton bones.

[0:00-10:36] When talking in terms of unique Animesh objects, the skeleton can be re-purposed to suit the need, and not all the bones need to be animated. So, for example, in a grouping of plants, the leg, arm, wing, and tail bones could be used to animate individual plants (in principle, individual finger bones could be used).

As with any use of the skeleton, the important aspects are preserving the recognised bone naming and parenting hierarchy (although it is possible to constrain bones  / bone groups for specific uses within Blender, then map this back to the SL skeleton, but it requires care and attention with a thorough understanding of the SL avatar).

This is where Animesh is attachments such as hair is of an advantage over hair that simply uses with avatar’s own skeleton. With the latter, the available bones are limited without potentially impacting the ability to wear animated hair with a Bento head (although there are “spare” ear and eye bones which could potentially be used to create an animated ponytail or pigtails).

Using a separate range of bones in Animesh hair offers greater flexibility – but then the issue becomes keeping the animations in the Animesh hair in sync with the movements of the avatar wearing it.

“Dropping” Animesh / Mesh

[11:50-15:31] Worn mesh cannot be simply “dropped” in-world. It has to be detached to inventory and then rezzed in-world from there. This has been seen as limited with Animesh pets, etc., where ideally people might want to pick a pet up and carry it and then put it down again (drop it). Making it possible to drop mesh is seen by the Lab as “kind of a hassle to do”, but it’s not currently clear how big or small a hassle it might be, as it would involve additional land impact calculations, physics updates, etc., none of which were given support when mesh was introduced. Thus, it could require  an extensive simulator-side overhaul.

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, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

  • The current work to update the baking service to support 1024×1024 textures.
  • An intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

Viewer work has paused while some back-end baking service issues are resolved.

Other Items

How the Lab looks at Features

One oft-phrased point-of-view is that the Lab “only” think about features being used in a certain way – and this has at times been voiced for Animesh. Speaking at the meeting, Oz Linden sought to dispel this idea, pointing to the diverse ways capabilities are frequently used in SL.

 

Mesh Uploader

[18:15-22:44] Cost calculation issues: discussion on mesh upload costs noted in the viewer. These have long been an issues, where costs can alter due to the same model being automatically decimated differently with each upload, etc. These are most likely the result of errors in the calculations framework, and they are something the Lab is aware of, and might be the result of the removal of the SLM file from the uploader, which caused problems of its own. Those who wish to test whether the cost calculation issue is reduced by using the SLM file can do so by setting the MeshImportUseSLM debug to True.

[23:32-24:22] Mesh object names: Vir reminded people due to a limitation with Collada .DAE files mesh objects for upload via the official viewer cannot currently have spaces in their names. However, the Lab will be adopting the Firestorm work-around for this by allowing the use of underscores in object file names.

Bone Offsets

[26:44-29:18] Bone offsets: Vir points to an issue he encountered with an avatar model using a 75m offset for the mPelvis bone which, every time the offset was calculated, would cause the object to vanish from his screen until Reset Skeleton was used. This prompted the question whether should bone offsets have a constraint of bone offsets – such as no more than 5 metres, as is the case when offsetting using animations.

SL Viewer

  • The Wolfpack RC viewer (containing no functional changes to the current release viewer) updated to version 5.0.10.330113 on Wednesday Novermber 20th, 2017.
  • Nalewka Maintenance RC updated to version 5.0.10.330123 on Thursday, December 21st, 2017.

These likely mark the last viewer updates for 2017, leaving the rest of the viewer pipeline as follows:

 

SL project updates 50/2: Content Creation User Group

Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, December 14th, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. 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, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Time stamps in the body text will open the video in a separate tab for ease of reference to the relevant parts of the text. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.

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, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

  • The current work to update the baking service to support 1024×1024 textures.
  • An intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

[1:54-3:40] Testing of the updated baking servers to handle 1024×1024 is now complete. Originally, it had been thought that the Bakes on Mesh would require changes to objects themselves when using 1024×1024 textures, which would have required simulator updates as well.

The approach now being taken is the let the viewer recognise when 1024×1024 textures are being handled via the texture UUID, which should hopefully eliminate any simulator side updates as well in order to get the service running. However, this does raise the question of how to make the system avatar transparent / invisible without continuing to rely on an alpha mask – right now the Lab is looking at a number of possible approaches.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.

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. It involves both viewer and server-side changes.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.
  • Will not support its own attachments in the initial release.

Note that the focus of this project is not currently about providing fully functional NPCs at this point in time, which is seen as a follow-on project.

Resources

Appearance Service Update

[4:28-6:18] The appearance services has to perform a number of calculations based on the mesh attachments an avatar is wearing. For example, these calculations are run to try to ensure an avatar appears to stay reasonably on the ground  when wearing a rigged mesh which might otherwise alter the avatar’s centre position above the ground.

These calculations don’t work particularly well for Animesh attachments, as they have their own skeleton, so the appearance service has been updated so it can differentiate between Animesh and non-Animesh attachments for the purposes of calculating and avatar’s height. The update is being tested on Aditi, and also includes a fix for rigged mesh attachments being incorrectly handled.

Viewer Status

[6:21-8:01] The Animesh project viewer updated to version 5.0.10.330058 on Monday December 11th. This updates includes the following changes:

  • Animesh objects should now display correctly as impostors, using the same rules that avatars do currently.
  • Animesh objects now display animation information for objects you have permission to view.
  • Fix for a crash triggered by unchecking the animated mesh check box for an Animesh attachment.
  • Fix for Animesh attachment getting removed after teleport.
  • Fix for some of the cases where animesh graphics state could get corrupted.
  • Various clean-ups and optimisations.

[6:32-7:30] There is also a forthcoming fix to the mesh uploader – not in the viewer version above – and mesh attachments with spaces in their names (actually a Collada file issue). In short, the Lab is implementing a similar kind of fix to that used by Firestorm to allows objects with underscores in their names, rather than spaces.

Testing Limits: Tri Count Increased to 50K

[8:07-9:03] There has been a lot of feedback that the 20K tri count limit imposed for testing Animesh is insufficient for some creators. In fairness, some of the complaints appear to be more to do with testing completed Animesh products rather than testing the Animesh capabilities to ensure they work as expected; however, the Lab has relented and increased the testing limit on tri counts to 50K. Again, this isn’t the final limit – it is purely for testing. Final limits – hard or soft, tri, number of attachment, LI, etc., – won’t be addressed until actual load testing and scaling takes place as one of the final steps in the project.

Avatar Animesh Attachments

[12:27-19:40] (with lengthy silences)] Other limits, such as the number of Animesh attachments an avatar can wear (set to one for testing) remain unchanged at this point.

Attahments are seen as an interesting use-case with suggestions that as well as pets, it could be used for further animating hair (as rigged mesh hair can already be somewhat animated with head movements, etc). The latter is something that it was suggested Bento might further achieve (bones allowing). Using Animesh would provide more bones for animating hair, but ensuring animations remain in sync with body movements might be difficult.  It could allow hair to be a “pet” (a Medusa-like heads for of snakes).

Attachments for Animesh Objects

[24:45-32:18] Animesh will not support attachment swapping in the initial release – attachments will need to be defined as part of the overall Animesh. Adding / removing attachments is seen as part of the follow-on project.

This section includes discussion of a specific prim-based issue with Animesh encountered by one creator, and a discussion on non-rigged elements of Animesh objects not correctly moving with the rest of an Animesh object (e.g. unrigged eyes failing to properly move with the rest of an Animesh creature’s head).

Bugs Focus

[19:56-23:00] Vir’s current focus for the project is bug fixing. These include:

  • Some Animesh objects seeming to disappear when in their static (non-animated) state.
  • Left-click interactions with Animesh: it’s possible to right-click and Touch an Animesh object via the menu, but left-click interaction currently isn’t possible. Left-clicking on multiple Animesh objects to select them also isn’t possible at present.
  • Animesh LOD selection: currently the selection of the LOD for displaying an Animesh is the same as used for avatars; Vir’s feeling is that Animesh should use the same selection process as for in-world mesh objects.
  • Animesh objects do not always update correctly when camming onto them.

There are also a couple of feature requests that are still being considered around LSL capabilities.

In Brief

  • [34:23-35:22] Avatar skeleton as its own asset type? This has previously been discussed in the Bento project, and while an interesting idea, is seen as being a large amount of work and crosses into the realm of arbitrary skeletons, which could complicate the user experience (e.g. items working with one type of skeleton, but not another).  As such, it remains something the Lab isn’t currently considering, although it may be something they will look at in the future.
  • [39:49-52:06] Discussion on rez-on-entry resource caps, issues of Animesh animations starting / stopping correctly, and how updates are handled – how people see an Animesh that is already in a region being animated can depend on the frequency of the animation updates. The potential need for a shape to effectively place bones / attachments.
  • [54:35-end] Discussion on feature request BUG-139203 tri counts / land impact / LODs and issues / exploits.

 

SL project updates 48/2: Content Creation User Group

A rally of (Animesh) raptors on Aditi

The majority of the following notes are taken from the Content Creation User Group meeting, held on  Thursday, November 30th, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. 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, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Time stamps in the body text will open the video in a separate tab for ease of reference to the relevant parts of the text. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.

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. It involves both viewer and server-side changes.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.

Note that the focus of this project is not currently about providing fully functional NPCs at this point in time, which is seen as a follow-on project.

Resources

Viewer Status

[0:13-1:06] The Animesh Project Viewer should be updated soon, bringing it into parity with the new release viewer (see below). This update will also include a couple of bug fixes.

Non-Rigged Root Items

[6:25-11:12] A short discussion on the ability to include non-rigged objects in an Animesh, such as an invisible prim as the root. This ability was recently added, but hasn’t been extensively exercised as yet. It sparked a look at BUG-139336, with Vir agreeing that the proposal need to be re-examined, as he is not sure if a scripted offset is the best answer, or whether allowing a manual offset through the build tools might be better. This feeds into a later conversation [35:27] about having LSL capabilities for all edit capabilities – and the risk of over-use of options as a result, simply because they can be automated – and the benefits of only making new capabilities (such as BUG139336) only available through LSL, where it might not be obviously to many, rather than being made visible through a build option.

Mod Keys

This was the subject of extensive discussions at the previous CCUG meeting. However, Vir again confirmed that it is viewed as something outside of the immediate Animesh project.

Performance Testing

[12:00-22:00] This is also a popular topic, and Vir re-iterated that it will be done, once the Lab feels this iteration of Animesh is “feature complete”. While he believes this is pretty much the case (allowing for bug fixes), he’d still rather hold off on testing a little longer. In the meantime, there continue to be calls for the current limits on tri counts, Land Impact, etc., to be relaxed to give people greater freedom to design Animesh. Vir is hesitant to do this, as he’d rather start from a constrained baseline with more structured testing to ensure sensible limits are arrived at which can be sustained across the entire grid when Animesh goes live.  Given the way that current mesh avatars are some of the more render-intensive (and viewer performance hitting) objects within Second Life, his concern is perhaps understandable.

[36:35-46:30] Some would like to see the tri limit raised to around 50K to allow for testing of products, rather than testing Animesh itself. This seems to be a little premature. However, Vir is going to discuss the potential for an tri limit increase with Alexa.

[22:42-27:53] A discussion on Animesh scaling, animation size and LOD. If an Animesh is based around a 0.5 cube, but the associated mPevlis bone is scaled to allow a 60-metre tall Animesh, what are the LOD calculations based on: the visible size of the object / distance from it, or the size of the root prim / distance from it (which would cause the Animesh to decay faster as the camera moves away from it).  Vir believes it should be based on the displayed dimensions, but notes there are already issues with meshes load the correct LODs.  As such, he’ll look into it some more.

[28:18-30:00] Further discussion on Animesh Land Impact, the arbitrary / testing only nature of the current 200 LI limit, toggling Animesh items on / off to help reduce LI, the potential of having a separate LI for Animesh objects compared to other in-world objects, and the complexities of doing so, were it to be pursued.

[30:56-32:46] LSL function for converting objects to Animesh and back – suggested as a means of lowering LI on items (so someone could use scripted controls to switch between, say, the active Animesh animals on their land. Again, Vir feels people might be getting a little too hung-up on the LI (and other limits) too early.

[46:42-51:50] Brief discussion on model orientation. As previously noted, Second Life expects a mesh to be X- oriented, so the front of the mesh is aligned to the X-axis. Blender can sometimes orient to the Y-axis. As a known bug, Vir is hoping it can be resolved through Blender, rather than by diving into the viewer code.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.

Current Status

[1:18-409] Rider Linden is working on the server-side updates so the simulator can support the new environment settings used by the viewer. When this is done, he’ll be working on saving the environment settings as inventory objects. The first implementation of these objects will be as day cycles, skies, and water – and are set-up to be expanded in the future.

There should hopefully be project viewer available (testing most likely on Aditi) after the Christmas / New Year break.

Continue reading “SL project updates 48/2: Content Creation User Group”