Tag: Content Creation 2018

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, August 30th, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

The choppiness in some of the audio segments where Vir’s voice drops out is due to issues with SL Voice. Topics blow are not necessarily presented in the order in which they were discussed, I’ve attempted to group items by subject matter.

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.

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh – Updated Limits and Cost Formulas
• Animesh feedback thread
• JIRA filter for Animesh

Current Status

In support of the server end of Animesh being grid-wide, and the viewer being in RC status, Vir Linden posted an update to the Animesh discussion thread in the forums.  The post underlines the point that now is the best time for some final testing of the initial Animesh capability before it rolls forward to a formal release in the not-too-distant future, when it will be harder to make changes out of concern for breaking existing Animesh content.

In particular, the post makes mention of the fact that moving forward, Animesh will see a behavioural change:

We will be enforcing a size limit on Animesh objects. This will give more consistent behaviour with other types of prims, for which size limits are enforced. The exact details of how this will work is still to be determined, but you should assume that Animesh objects cannot become arbitrarily large.

The reasons for this is that there is no upper limit imposed on rigged mesh objects (whereas all other types of in-world objects have a limit), and there is a concern that if Animesh is not capped, then people could make very large objects that generate rendering issues for those viewing it (see BUG-225331 for more), or as a means simply to grief.

What the limit is and how it is to be enforced is still TBA, but at the CCUG meeting, Vir indicated that the real-time bounding box calculations may be leveraged.

One bug the Lab are trying to poke at is “stuttering” with some Animesh motion. The underlying cause of this has yet to be identified.

Animesh and Resetting the Skeleton

Vir asked the question on when should a skeletal reset occur on an Animesh objects. For example: an Animesh dog has accessories that can be attached / detached by adding / removing from the linkset via script. Should the skeleton for the dog be automatically reset from the removal of an attachment, or should it be a manual reset by the user? Most attachments may not require a reset, unless they were altering the dog’s shape; however, forcing a reset could also mean any animations running on the Animesh would also have to be reset, making things a little complicated. The consensus opinion swayed towards leave things as is, rather than force a reset, and allow creators determine how to handle things.

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 viewer and 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.

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

Resources

• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

Bakes on Mesh is still awaiting the main grid deployment of the AIS updates needed to support the new Bakes on Mesh (and EEP) asset types. As noted in my previous CCUG summary, Bakes on Mesh also requires updates to a number of back-end services (e.g. the Bake Service), and to the simulator itself, all of which have yet to be implemented. The viewer, meanwhile is more-or-less ready, but may see a further project status update.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including:

• The ability for region / parcel owners to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
• New environment asset types (Sky, Water, Days that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Day assets can include four Sky “tracks” defined by height: ground level (which includes altitudes up to 1,000m) and (optionally) 1,000m and above; 2,000m and above and 3,000m and above, plus a Water “track”.
• Experience-based environment functions
• An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.
• There are no EEP parameters for manipulating the SL wind.
• EPP will also include some rendering enhancements  and new shaders as well (being developed by Graham Linden), which will allow for effects such as crepuscular rays (“God rays”)
  • These will be an atmospheric effect, not any kind of object or asset or XML handler.
• The new LSL functions for finding the time of day according to the position of the windlight Sun or Moon have been completed,and are more accurate than the current options.
• EEP will not include things like rain or snow.
• It will still be possible to set windlight local to your own viewer.

Resources

• Project definition document.
• Project summary (this blog).

Current Status

EEP is now described as being “very, very close” in terms of server-side support and a project viewer.

An issue with testing has been that a long-standing bug on Aditi (the beta grid) has meant that the Lab has been unable to set parcels them for sale, allowing users to purchase them (funds on Aditi are provided by the Lab – and are non-transferable to Agni! – so purchasing land there is effectively a zero-cost transaction to the user) and then carry out their own EEP testing. This issue has now been resolved by Rider and Ekim Linden, so parcels are now available on the beta grid for those wishing to test EEP once the EEP project viewer is available (as the necessary viewer-side update will initially be in that viewer), and assuming the server-side support hasn’t already been deployed to Agni to allow testing on the main grid.

Other Items

Animations: Obtain by Name or UUID? A Case of Permissions

The middle of the meeting saw a discussion on whether calling animations by name or UUID is “more secure”. In short, calling by name requires the animation to be in an individual’s inventory, and thus seen by the Lab as more secure in preventing theft. Calling by UUID opens the potential to animations being physically obtained from the CDN should the UUID be unfairly obtained.

The question was prompted out of concern that is it possible to remove animations (and other items) from No Modify objects ad use them elsewhere – which (it seemed) one or two creators want to prevent. This comes down to more to how the permissions system works, more than anything else (No Modify means an object cannot be physically altered or added to; it does not mean its existing contents cannot be removed). Preventing the removal of an objects contents (whether animations or anything else) would require a significant overhaul of the permissions system.

Link / Unlink Permissions for Experiences

A request was made no adding the ability for experiences to be able to request permission to link / unlink objects without the need for individual requests to be made for each link / unlink operation – something which could be useful with Animesh. This has been discussed in the past, but is seen as being a larger project than something specific for Animesh, although it is seen as a useful capability (along with the means to offer mod keys for No Modify objects). Right now it is unclear what form such a project to provide capabilities like this would be, or where it would fit in the overall SL enhancement roadmap.

In Brief

• Release Candidates and Project Viewers: generally speaking, if you are using either a Second Life release candidate viewer or a project viewer, you will not be automatically updated to an other viewer version, but you will be updated to the next available version of the RC or project viewer you are using, by the viewer update process. The exceptions to this are with RC viewers – such as the promotion of the viewer to release status (you will receive updates to later release promotions unless you opt to use another RC), or the RC is withdrawn (you will generally be updated to the current release viewer). Details on the release candidate viewer process can be found in my 2013 post: New viewer release process implemented.
• Experience Keys: Oz confirmed that there is a plan to allow Premium users to have more than one experience key (allowing them to make multiple individual experiences, rather than having to use the same one for different purposes). The time frame for when this will be implemented is still TBD, as it requires a certain amount of back-end work.
• Date of next meeting: Thursday, September 13th, 2018.

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, August 23rd, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

The choppiness in some of the audio segments where Vir’s voice drops out is due to issues with SL Voice.

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.

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh – Updated Limits and Cost Formulas
• Animesh feedback thread
• JIRA filter for Animesh

Release Candidate Viewer

As noted in my Simulator User Group updates and Viewer Release summaries, the Animesh viewer was promoted to release candidate status in week #33 with the release of version 6.0.0.518579 on August 13th, 2018. The three key points of this are that:

• Animesh is one step away from being the de facto viewer release – although this is dependent on a range of factors, including the other RC viewer in the pipeline, the viewer’s performance whilst at RC, etc.
• Animesh capabilities will now naturally be available more widely among users of the official viewer.
• Third-party viewers are now officially allowed to incorporate Animesh in their offerings.

Server-Side

Animesh has been on general release server-side across the grid for the last couple of weeks, and thus far, no problems have surfaced with in. However, this could be due to a relatively low usage of the capability up until now, given it has only be available within project viewers.

Sample Content Rotation

As noted in past CCUG summaries and updates in these pages, a  workaround for rotation issue with uploaded models now means that some of the Animesh sample content provided by the Lab – such as the raptors used in the GIF file I often use to banner these reports – now crab sideways rather than walking forward when seen in the Animesh viewer.  Following a suggestion put forward at the meeting, Vir is going to see if the affected content can be updated so that it moves correctly and can be provided as samples for people wanting to play with Animesh without potentially confusing them.

It’s also been pointed out that the scripts used within the sample content are very specific to that content, and so could lead to problems if people try to pull the scripts and use them as templates. However, Vir is uncertain as to how generic the scripts can be made in order for them to work as templates.

Bugs

There are still a number of bugs the Lab is working on in relation to Animesh. These should be listed in the JIRA filter (link above), and are related to some Animesh editing issues, animation stop / restart issues, and some lagging, possibly due to the underlying skeleton lagging behind the animation playback (so the Animesh isn’t properly oriented as an animation starts to play, for example). Not all of these issues may be fixed before Animesh reaches de facto release status, but Vir is continuing to try to work through them.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including:

• The ability for region / parcel owners to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
• New environment asset types (Sky, Water, Days that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Day assets can include four Sky “tracks” defined by height: ground level (which includes altitudes up to 1,000m) and (optionally) 1,000m and above; 2,000m and above and 3,000m and above, plus a Water “track”.
• Experience-based environment functions
• An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.
• There are no EEP parameters for manipulating the SL wind.
• EPP will also include some rendering enhancements  and new shaders as well (being developed by Graham Linden), which will allow for effects such as crepuscular rays (“God rays”)
  • These will be an atmospheric effect, not any kind of object or asset or XML handler.
• The new LSL functions for finding the time of day according to the position of the windlight Sun or Moon have been completed,and are more accurate than the current options.
• EEP will not include things like rain or snow.
• It will still be possible to set windlight local to your own viewer.

Resources

• Project definition document.
• Project summary (this blog).

Current Status

Alex Linden from the product team has been working on internal testing with Rider, and is now in the process of moving the pieces into place to have EEP deployed the Aditi (the beta grid).  Rider believes that a project viewer should be surfacing “very, very soon” as a result.  The plans for the project viewer are:

• • Get the assets support in to the first release.
  • Hopefully include crepuscular rays (“Godrays”) and work on shaders for distance fogging and atmospheric density in the first release of the project viewer as well. However, as these are in fact another shader, they may not make it into the initial cure of the project viewer, depending on how things go.
  • Add the scripted ability to manipulate EEP assets at a later date, but before the viewer progress to RC status.

As well as discussing project progress, Alexa and Rider also indicated some of the things they’ve been playing around with while testing EEP.

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.

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

Resources

• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

Still awaiting the AIS updates (see below). Once these are in place there are a couple of other back-end pieces that require putting into place.

AIS Update

Both EEP and Bakes on Mesh are awaiting a AIS (Advanced Inventory System) update that will provide the necessary back-end support for both projects on Agni (and Main grid), as each is adding new inventory asset types to Second Life. Currently, it is believed that the work on support for Bakes on Mesh is a little further along to allow it to take advantage of the AIS update, and the latter may start being deployed in week #35 (commencing Monday, August 27th, 2018).

In Brief

• In-world meshes bigger than 64m on an axis: there are no current plans to allow the upload of in-world meshes that exceed the 64m limit.  The main reasons for this are:
  • Vertex resolution: the larger the object, the greater the distance each vertex integer has to span, leading to inaccuracies in positioning (think prim drift for mesh), together with resolution degradation.
  • More particularly, the griefing potential and possible performance issues (e.g. rendering load on the viewer and possible implications for the physics engine).
• Sim surrounds: partially in line with the above (and also ARCTan, below, given the use of sculpts), the Lab is interested in learning more above how people might like sim surrounds to be addressed. Some ideas offered include: making surrounds a specific form of large mesh with physics automatically disabled at upload (possibly used with a special field within the Estate / Region floater they can be “dropped into” to be applied; continuing with sculpts (with their 1 LI advantage over other potential land impact loads & their potential to have a relatively low number of vertices and thus form relatively economical content).
• Project ARCTan: the project to recalculate object and avatar complexity will be progressing, however, it involves input from Graham Linden, who is currently focused on the shader / rendering work for EEP.   However, data collection is continuing.
  • People are starting to question what this will mean for sculpt(ie)s in SL – the majority of which tend to be horribly inefficient in terms of rendering. The short answer to this at the moment is the overall impact hasn’t been determined.
• Real-Time bounding box tracking: the question was asked whether the new bounding box calculations introduced as a part of Animesh will include “unused” joints (e.g. if the hind legs in the skeleton are not rigged to, are they included in the bounding box calculations?). short answer: no; with the exception of the original (pre-Bento) base skeleton joints (as used by the system avatar).
• Next Meeting:  Thursday, August 30th, 2018.

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, August 9th, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

The choppiness in some of the audio segments where Vir’s voice drops out is due to issues with SL Voice.

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.

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh – Updated Limits and Cost Formulas
• Animesh feedback thread
• JIRA filter for Animesh

Server-Side

As of the SLS (Main channel) grid deployment on Tuesday, August 5th, the server-side support for Animesh is now grid-wide.

Animesh Viewer

Vir has completed work on the next update to the viewer, which includes a number of fixes and tweaks. This is currently with the Lab’s QA team. If all goes according to plan, this could see the light of day as a Release Candidate viewer. In particular, this update should include a fix for the bounding box / LOD issues previously reported in these summaries.

General Discussion Points

• The LI accounting aspect of Animesh is considered “complete” for the initial release, and no further changes beyond the accounting values Vir has published via the Animesh forum thread are expected.
  • However, there may still be future revisions to the overall Animesh costs (complexity) as a result of the Project ARCTan work to overhaul all of the complexity calculations in order to make them more reflective of the actual costs involved in rendering, etc., different objects. This work has apparently been on hold recently.
• Land Impact: streaming costs / LODs: there was further discussion on the 50% bounding on LODs.
  • Concerns have been raised at the disparity between the 50% cut-off between the high and medium models compared to the GLOD (Global LOD) cut-off of around 30% (so 70% discarded). Other concerns relate to the 50% between the medium and low models disincentivising creators from trying with a low model. An overall concern is that people will continue to look purely at land impact, rather than considering complexity and optimisation as matters of improved performance.
  • Vir admits the approach taken with Animesh is something of a trade-off between trying to encourage considered use of LODs and implementing a system that “scares people off” because of its demands. As such, it is something that may be revisited as a part of ARCTan, after more data has been gathered as a result of Animesh being released in the meantime.
  • A major difference with the “new” system is that it no longer considers scale. This means that creators who animate their creatures using a combination of multiple models and using alpha masks to hide the “unseen” versions and who reduce the “unseen” models to avoid them raising a creature’s LI, will no longer be able to do so.

• Per-bone scale animations: having the ability to use per-bone scale animation, which could be particularly useful for non-human bodies (and now Animesh) has been  a request since Bento.
  • Currently, the SL animation format doesn’t allow scales to be specified, so an overhaul of the animation system would be required to make this possible.
  • A further problem is scale animation can conflict with any use of the shape sliders, when used to modify an avatar shape (one of the items under consideration for a future update to Animesh is support for a body shape and the use of sliders).
  • The benefits with scale support include:
    • The ability to create a single creature body and use it in different species of that creature without the need to develop new animations and new rigged attachments (so a “dog” body could be used for a Labrador or a Chihuahua or Dashhound).
    • The ability to have “young” creations (babies, puppies kittens, hatchlings….) “grow” over time.
    • The ability for creators to develop a broader range of different NPCs and different creature types without having to rely on the avatar shape / slider system, which is inherently biased towards human forms.
  • An alternative to animation scaling (and subject of a feature request) that was initially made during Bento, was to have an overall body size slider that could proportionally adjust the entire size of the shape associated with an avatar (and Animesh, if shape and slider support is added to Animesh in the future).
    • One issue with implementing this at present is that the message format use to communicate slider parameters may not support the level of messaging required to communicate an overall rescaling that affects every joint and bone position at once (which would require updates to the Appearance  and Bake services as well, so this would require an overhaul.
    • A further issue is that of locomotion:  the same overall locomotion graph is used regardless of size, so in a single stride, a very tiny avatar made using a “size slider” could  appear to move the same distance as a “normal” sized avatar, which can result in it appearing to move really quickly;similarly a really tall avatar created using a “size slider” could appear to hardly move at all each time it takes a step. So, the locomotion graph would need to be overhauled.
  • Use of per-bone animation scaling hasn’t been ruled-out, with Vir pointing out that even adding body shape and slider support to Animesh is complex, requiring further updates to the Appearance and Bake services in order to work. So it might be something to consider alongside of considering shape / slider support once the initial Animesh project is released.

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.

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

Resources

• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

There do not appear to be any blockers within the project preventing it from moving forward. However, as indicated at the July 27th TPV developer meeting, there are some changes being made to the AIS system, and the updates to inventory required in support of Bakes on Mesh (which also requires updates to the Appearance and Bake services as), are currently awaiting that work to be completed.

Environment Enhancement Project

Project Summary

A set of environmental enhancements, including:

• The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
• New environment asset types (Sky, Water, Days that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Day assets can include four Sky “tracks” defined by height: ground level (which includes altitudes up to 1,000m) and (optionally) 1,000m and above; 2,000m and above and 3,000m and above, plus a Water “track”.
• Experience-based environment functions
• An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.
• There are no EEP parameters for manipulating the SL wind.
• EPP will also include some rendering enhancements  and new shaders as well (being developed by Graham Linden), which will allow for effects such as crepuscular rays (“God rays”)
  • These will be an atmospheric effect, not any kind of object or asset or XML handler.
• The new LSL functions for finding the time of day according to the position of the windlight Sun or Moon have been completed,and are more accurate than the current options.
• EEP will not include things like rain or snow.

Resources

• Project definition document.
• Project summary (this blog).

Current Status

EEP remains on internal testing at the Lab, although as I noted in my previous CCUG summary, Rider has been teasing us with images in the forums. According to Dan Linden. the viewer UI is “pretty much” complete, and work is focused on some of the back-end messaging, which appears to be holding things up. There may be a further update on status at the next TPV Developer meeting on Friday, August 10th.

Other Items

• Transparency shadow casting from rigged items: there is an issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by them to render incorrectly (shadow rendering conforms only to the geometry silhouette).  This is still within Graham Linden’s pile of work.
• Next Meeting: the next CCUG meeting for August 2018 will take place on Thursday, August 23rd.

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, July 26th, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

Note that the audio presented here may not be in the exact order of discussion during the meeting; as subjects were at times returned to following their initial discussion, I have attempted to bring together key points of discussion by topic / subject matter. Also, please note that audio drop-out when Vir is speaking appears to be an ongoing Voice issue.

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.

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh – Updated Limits and Cost Formulas
• Animesh feedback thread
• JIRA filter for Animesh

Viewer Status

The Animesh viewer updated to version 6.0.0.518080, which appeared in the pipeline on Wednesday, July 25th.  It comes with the following notes:

It has a fix for a bug that caused rigged meshes to fail to display intermittently [BUG-225063]. There is a significant change to orientation handling for Animesh objects in this build. If you make an Animesh object from a linkset that contains a rigged mesh as the root object, then the rotation for the object will be corrected to try to make the rigged display line up with the physics representation (correction is based on the bind shape matrix). This will change the behavior of some existing content – for example, the gift raptors on Agni are now rotated 90 degrees. Content that uses a non-rigged object as the root should be unaffected by this change. LOD calculations for Animesh objects now use the dynamically updated bounding box, so they should be more accurate and consistent.

The rotation fix does have an impact on some content, which can end up moving “sideways” compared to the expected direction.

Additional Work for Animesh to reach RC Status

• Server-side: Vir is currently trying to track done the cause of some server issues which are probably the result of the simulator having to “remember” a lot more information with Animesh, and failing to do so properly, which can impact things like streaming costs.
• Viewer-side: still some outstanding work to be done with getting LODs to behave / display consistently.

Both of these are seen as requiring resolution before the Animesh viewer moves to release candidate status.

Future Animesh Work

• There has been some discussion about possible follow-on projects for Animesh, but no final details on what will be in the mix has been made.
• Animesh customisation, including assignment of a body shape is considered to be “high” on the list of follow-ups. However, no decisions have been made on whether:
  • It will include LSL support for customisation.
  • It will add body shape support (and the use of the body sliders for customisation.
  • It might include an extension to Bakes on Mesh for Animesh.

Animesh and Scale Animation

Scale animation is something that has been requested since Bento. However, the problem here is the SL animation format doesn’t have any notion of scale animations, so in order for support to be added, the entire animation system would require an overhaul.

Another issue, as found with Bento, is that things can become tricky (if not confusing for some) when animations and sliders are both controlling the same thing – as would be the case with scale animations (although this was eventually done with bone translations).

In Brief

• BUG-225153 “Animesh issue: Multiple faces don’t work – Reverts back to one texture when animation played”: this does not appear to have been reproduced by others, and it is unclear whether it is an issue, or something specific to the user.
• BUG-225158 “[ANIMESH ] Inconsistent default graphics settings with relation to current mainstream viewer as well as ‘recommended settings’ button”: this appears to be a change in how graphics settings are detected in the viewer in general, rather than specific to Animesh. further testing / investigation is required.

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.

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

Resources

• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

Still with the Lab’s QA team, and the viewer is internally flagged for product reviews, so a project viewer update could be appearing soon^TM. This should include a number of bug fixes that have been worked on recently.

In addition, Anchor Linden has been adding new LSL constants for the various Bake Channel textures, so that if someone wants to use LSL to change a particular face on a mesh object to use Bakes on Mesh, they will be able to do that using a constant.

A reminder for those trying to test Bakes on Mesh: the capability requires server-side support, which has not been deployed to Agni (the Main grid), but is only available on Aditi (the Beta grid) on the Bakes on Mesh test regions.

To prevent confusion, it’s been suggested the Bakes on Mesh viewer is blocked from accessing Agni until such time as the server-side support has been deployed.

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.
• New environment asset types (Sky, Water, Days that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Day assets can include four Sky “tracks” defined by height: ground level (which includes altitudes up to 1,000m) and (optionally) 1,000m and above; 2,000m and above and 3,000m and above, plus a Water “track”.
• Experience-based environment functions
• An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.
• There are no EEP parameters for manipulating the SL wind.
• EPP will also include some rendering enhancements  and new shaders as well (being developed by Graham Linden), which will allow for effects such as crepuscular rays (“God rays”)
  • These will be an atmospheric effect, not any kind of object or asset or XML handler.
• The new LSL functions for finding the time of day according to the position of the windlight Sun or Moon have been completed,and are more accurate than the current options.
• EEP will not include things like rain or snow.

Resources

• Project definition document.
• Project summary (this blog).

Current Status

• Rider Linden has been working on the viewer UI (presumably as a result of QA feedback). It is thought that a first cut project viewer is not that far away from appearance publicly.
• However, as EEP requires additional back-en changes which have yet to be deployed to Agni, it is likely that when the project viewer does appear, initially, it will only work on Aditi (the beta grid).
• Rider has also been teasing people with EEP-related images on the forums!

Other Items

• BUG-225157 “[RC BlueSteel 18.07.17.517953] Adjusting specular horizontal offset also adjusts specular vertical offset on BlueSteel regions only”: this has been imported into the Lab’s internal JIRA and may be receiving attention.
• Increase to maximum prim size: the current prim size limit in SL is 64m on a side. There have been calls to increase this to allow bigger meshes to be imported (e.g. large land forms for landscaping a region).
  • There are no plans to increase this limit in the immediate future, and it’s been pointed out that increasing the size could be somewhat self-defeating in that it results in a loss of vertex position resolution (vertex space being limited to 64K), which could result in odd artefacts occurring in uploaded models, and, as Elizabeth Jarvinen (polysail) succinctly put it, “your vertex positions will wobble like nuts at high altitudes”.
• Next Meeting: due to the Lab’s start-of-month internal meeting and vacations, the next CCUG meeting will most likely be on Thursday, August 16th – check the wiki page to confirm nearer the time.

 

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, July 19th, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

Note that the audio presented here may not be in the exact order of discussion during the meeting; as subjects were at times returned to following their initial discussion, I have attempted to bring together key points of discussion by topic / subject matter. Also, please note that audio drop-out when Vir is speaking appears to be an ongoing problem at his end.

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.

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh – Updated Limits and Cost Formulas
• Animesh feedback thread
• JIRA filter for Animesh

Rotation Issues

These cover a couple of issues:

• In one (BUG-139251), when some static mesh objects are converted to Animesh, the visual mesh is rotated through 90 degrees when seen in the Animesh viewer, but the physics mesh isn’t, leaving it perpendicular to the model. This is possibly an orientation issue, with the viewer expecting the mesh to be aligned to +x=forward – which not all mesh modelling tools follow.
• The second problem is that when linking a series of objects into a single Animesh, then are visually located where the avatar skeleton supporting them is located, but the physics shapes remain in the original location of the objects prior to linking / converting.

Both of these problems pre-date Animesh, but have been effectively “hidden” because until now, rigged meshes could only be attached to an avatar, effectively masking the issues.

As a part of the approaches to fix these issues, Beq Janus and Elizabeth Jarvinen (polysail) have contributed code to correctly apply the bindpose matrix within the viewer. This code is in the latest version of the Animesh project viewer, which should be available soon, and should cover legacy content not corrected by similar fixes incorporated into Avatasr for new uploads (see my week #26 CCUG summary for more on this).

LOD Issues

Vir is currently working on the server-side issues, but once those have been resolved, his plan is to work on the viewer-side LOD issues, including BUG-224971 and the Dynamic bounding box issues (see my week #25 summary). Once he has completed testing the fixes for these, the hope is that the Animesh viewer can move to RC status.

Mesh Physics Shapes Issues

The deployment of Animesh to the RC server channels has revealed a couple of issues which need to be resolved:

• Not all of the mesh information the server is required to “remember” is being properly retained.
• Code within the Animesh update appears to be causing some in-world mesh objects to use the wrong physics shapes.

In Brief

• Concern was raised whether Maya could be used to produce Animesh, given the rotation fixes seem to apply to Blender / Avastar. As Far as Cathy Foil (creator of Mayastar) is aware, meshes created in Maya / Mayastar can be converted for use as Animeshes.
• Animesh does not support custom bones – it works purely with the Bento skeleton, which does allow for bone re-purposing.
• BUG-225063 reports that the latest Animesh project viewer fails to display meshes at times, while older Animesh code can cause meshes to display incorrectly. Vir believes the issue may be linked to one he has been addressing, and believed to be caused by an uninitialised variable. The fix for this should be in an upcoming release of the viewer.

• BUG-216352 “[Animesh] Issue with animations not rendering if they were stopped and started while host object is selected” – this is still being investigated. However, as it only applies to the same animation, rather than all animations, the issue isn’t regarded as a blocker for Animesh.

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.

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

Resources

• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

Some people have been reporting some “excitement” when using the new universal bake channels for Bakes on Mesh in regions that don’t have the server-side support for Bakes on Mesh. These issues will likely require further viewer and server-side changes to fix them.

At a recent LL meeting on Bakes on Mesh it was decided not to implement any additional features at this point in time – so no LSL support prior to the initial deployment. Rather, the Lab would like to get a basic capability out that can be used and tested, then potentially improve on it with further features in time.

As it is, even moving Bakes on Mesh to release candidate status is dependent on a large number of back-end service changes (e.g. the inventory system must be updated to handle the new wearable types; the Appearance and Bake services must be updated, as well and the simulator and viewer updates.

Asa reminder, it will not be possible to use Bakes on Mesh with Animesh creatures / creations, primarily because Bake On Mesh uses the Outfit system, which Animesh currently does not – but may be extended to use in the future.

The question was asked if Bakes on Mesh could be used to texture an Animesh attachment to an avatar, and in theory it would be – but how useful / practical this might be is open to debate.

In Brief

• There will be a CCUG meeting on Thursday, July 26th, however, it comes on top of the SL summit meeting at the Lab (to discuss the SL development roadmap) and  so Vir believes there won’t be too much to report on additional work at the meeting.
• Concern has been raised over the recent DMCA situation involving around 3 makers of mesh heads, and whether Bakes on Mesh will see changes to the SL Terms of Service / guidelines specifically for UV maps (e.g. what is allowed, what isn’t), given that Bakes on Mesh could encourage the use of the basic SL UV maps and result in multiple claims of people “using” someone else’s maps. This concern is being passed back to the Lab’s legal team.
• The latter part of the meeting included a lengthy discussion on animations (adding a function to “instantly” stop an animation / being able to modify animation speeds / priorities in-world; the legitimacy of modifying animations) which also spread to the permissions system (providing  “export” permission to allow people to export “full perm” meshes for direct editing and re-upload and / or implementing a “derivative” permission.
  • Some of the animation discussion touched on the animation discussion may surface as a specific feature request(s).
  • It’s unlikely there will be any large-scale changes to the permissions system in the near future.

Eri-Ador – blog post

The majority of the following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, June 28th, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

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.

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh – Updated Limits and Cost Formulas
• Animesh feedback thread
• JIRA filter for Animesh

Current Status

• On Wednesday, June 27th, server-side Animesh support was deployed to all three of the major release candidate channels – Magnum, LeTigre as well as BlueSteel. Test regions for Animesh are as follows:
  • Animesh1 ; Animesh2 ; Animesh3 ; Animesh4 ; Animesh Adult
• The Animesh viewer remains at project status, but was updated to version 6.0.0.516979 on Monday, June 25th, 2018. The viewer is liable to remain at project status until the bugs currently being worked on have been resolved. These bugs include, but are not limited to:
  • Encroachment / Position / Offsets.
  • Rigged Mesh Level of Detail / Bounding Box Issues (BUG-214736).
  • Broken Rotations Issues (see below for more).
  • Dynamic bounding box issues: the project viewer (5.1.4.515420) includes updates for keeping dynamic bounding boxes going for rigged avatars (including Animesh). The calculations used in these updates for Animesh attachments “isn’t quite right” and the extent calculations can be incorrect (particularly if an Animesh object is being rendered as an imposter).
• Vir now has a number of issues related to level of detail which he is starting to dig in to, including BUG-224971.The revised bounding box calculations related to this will be in the next Animesh project viewer update.
• The z-offset issue with Animesh objects failing to respect z-offset height setting specified at upload for a rigged mesh should now be fixed.
• It’s been reported that while Animesh objects will show info in the same way as avatars do with Developer > Avatar > Animation Info is enabled, it reports different info to  llGetObjectAnimations()
  • This might be a bug.
  • It might be that the debug information isn’t updated on a frequent enough basis.
  • Either way, a bug report has been requested.

Rotation Issues

These cover a number of areas, including:

• In one (BUG-139251), when some static mesh objects are converted to Animesh, the visual mesh is rotated through 90 degrees when seen in the Animesh viewer, but the physics mesh isn’t, leaving it perpendicular to the model. This is possibly an orientation issue, with the viewer expecting the mesh to be aligned to +x=forward – which not all mesh modelling tools follow.
• The second problem is that when linking a series of objects into a single Animesh, then are visually located where the avatar skeleton supporting them is located, but the physics shapes remain in the original location of the objects prior to linking / converting.

Both of these problems predate Animesh, but have been effectively “hidden” because until now, rigged meshes could only be attached to an avatar, effectively masking the issues.

The recommendation for trying to deal with them at present is for Animesh objects to have a non-mesh root object, and associate any physics representation to that non-mesh root object. This should hopefully eliminate the current issues and help ensure that any mesh being propelled via scripts in the root object will move in a predictable manner (.i.e. moves forward when driven forward by a script).

There have been two user-led moves to try to resolve / reduce these problems:

• Beq Janus and Elizabeth Jarvinen (polysail) have also contributed code to correctly apply the bindpose matrix within the viewer.
• As the physical rotation issues tend to manifest with Avastar, it is being updates so that models are automatically oriented so that x+ is always forward. This may not help with all legacy content being converted to Animesh, but it should help with new content created via Avastar.
  • Vir has a concern that even with these changes, a  linked Animesh object using mesh items created in different tools might still exhibit unexpected behaviour – that an animation to move the Animesh forward might correctly drive the root mesh, but cause other elements to move (for example) sideways …
  • He also notes that the solutions don’t necessarily address the physics rotation / placement issue.
• It’s also been suggested the llLookAt provides documentation on what might be regarded for expected object behaviour.
• It has been pointed out that the orientation of a model can be checked in the mesh uploader preview window prior to upload, although the uploader doesn’t explicitly report an objects rotation.
• The debate on how best to approach the issues is likely to continue.

Animesh Attachments

• Animesh attachments are currently limited to one per avatar. This is viewed by some as too restrictive.
• This limit was set to allow the overall potential for a performance impact of attached Animesh objects to be limited (e.g. going to a club where everyone is wearing 4 or so Animesh attachments – hair, pets, and the like, all with their own skeleton and animation, all doing their own thing, could see the viewer take a significant performance hit).
• Some are seeing it as a tablets-of-stone limit and are wanting it raised from the outset (to between 2 and 3 Animesh attachments per avatar – in part, this appears to be due to a preference for using Animesh over the additional bones within the avatar skeleton for some attachments).
• Vir has indicated that the limit will not be increased during this initial deployment of Animesh, but the Lab will monitor the limit, and a possible future increase is not out of the question.
  • It is easier to relax an initial than it is to restrict them after rolling-out a capability – which is the situation the Lab wants to avoid (e.g. by – say – allowing 3 Animesh avatar attachments out-of-the-gate, then having to cut it back to 2 or 1 at a later date,due to the performance impact the capability is having).

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.

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

Resources

• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

• Anchor Linden is continuing to work on viewer-side bugs. In the next version of the viewer, an avatars appearance should correctly update in the Edit Appearance mode when changing applied textures.
• The project viewer updates are now with the Lab’s QA team. However, and update made to the project viewer doesn’t mean that it will be progressing to release candidate status just yet.
• As per my previous CCUG summary, the project viewer will not initially have LSL support for Bakes on Mesh – this will likely be added as the project as a whole iterates.

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.
• New environment asset types (Sky, Water, Days that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Day assets can include four Sky “tracks” defined by height: ground level (which includes altitudes up to 1,000m) and (optionally) 1,000m and above; 2,000m and above and 3,000m and above, plus a Water “track”.
• Experience-based environment functions
• An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.
• There are no EEP parameters for manipulating the SL wind.
• EPP will also include some rendering enhancements  and new shaders as well (being developed by Graham Linden), which will allow for effects such as crepuscular rays (“God rays”)
  • These will be an atmospheric effect, not any kind of object or asset or XML handler.
• The new LSL functions for finding the time of day according to the position of the windlight Sun or Moon have been completed,and are more accurate than the current options.
• EEP will not include things like rain or snow.

Resources

• Project definition document.
• Project summary (this blog).

Current Status

• Work is progressing on the project viewer, which should be appearing Soon^TM – possibly in the next two weeks, with back-end EEP support available on Aditi (the Beta grid) – supported regions TBD.
• There is a long-term issue with land ownership on Aditi which is unlikely to be resolved before EEP is deployed to Aditi.  This means that it is likely the Lab will set up a series of test parcels on Aditi and assign them to people manually for testing EEP capabilities at parcel level.
• It’s not clear how walls and other structure will affect crepuscular rays.

Additional Discussions

Particle System Updates

Particle wizard Tyrehl Byk (learn more about his work here and here) is back in Second Life and looking to produce more of his stunning shows. In the meantime, he has filed a feature request to improve particle capabilities in Second Life (see BUG-214757 – “Within the current llParticleSystem parameters, three new data points would be established that could be referenced by a particle script which would facilitate an exponential change in how particles are seen by SL residents”).

Oz Linden has indicated this is something the Lab would like to implement; however, while the feature request has been imported for tracking in their internal JIRA,they currently do not have the viewer-side resources to take on the work.

That’s one I would like to have had … The hardest part of that one is the viewer side, because that’s where the particle stuff actually happens. So if you’re interested in accelerating that one, Tyrehl, then find a third-party viewer dev who will dummy up the support in the viewer, then we’ll be able to do the server-side relatively easily.

Oz Linden on feature request BUG-214757

So if there is a third-party viewer developer out there who is interested in working with Tyrehl on this feature,please contact him in-world.

Get Animation Length

While not specific to Animesh, but seen as potentially useful, is a long-starting feature request, VWR-12518, “llRequestInventoryData() – Get length of an animation (in seconds)”.

A problem here is that at present, the simulator doesn’t actually read the contents of animations to ascertain what they are doing, how long they run, etc (while there is some analysis carried out during the animation upload process, this information is not retained for later use). So for an idea like this to be implemented would require a considerable amount of server-side work which might also have performance implications, as such this request is unlikely to be implemented unless part of a much large overhaul of back-end animation support.

Next Meeting

The next Content Creation User Group meeting will be held on Thursday, July 19th.