Category: Content Creation User Group

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.

Devin’s Eye – blog post

The majority of the following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, June 21st, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, 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.

SL Viewer

The Pálinka Maintenance RC viewer, version 5.1.6.516459 and dated June 15th, 2018, was promoted to de facto release status on Thursday, June 21st, 2018.

The 32-bit Windows Unloop RC viewer, version 5.1.6.515965 and dated June 5th, 2018, was also withdrawn as it is no longer required with the promotion of the Pálinka  RC viewer.

This leaves the official viewer pipelines, at the time of writing, as follows:

• Current Release version5.1.6.516459 and dated June 15th, promoted June 21st – formerly the Pálinka Maintenance Release Candidate – New.
• Release channel cohorts:
  • No viewers (at the time of writing, but a new Maintenance RC is expected).
• Project viewers:
  • Bakes on Mesh project viewer, version 5.1.6.516270, dated June 14th.
  • 360 snapshot viewer, version 5.1.6.515934, June 6 (see my hands-on update).
  • Animesh project viewer, version 5.1.4.515420, dated May 14 – project overview.
• Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
• Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

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

As noted in my report here (and the official announcement from the Lab), the server-side code for Animesh was deployed to the BlueSteel RC as part of the ongoing developing and testing of the capability. For those wishing to test Animesh, there are also five dedicated Animesh test regions available (all obviously on BlueSteel at this point in time):

• Animesh1
• Animesh2
• Animesh3
• Animesh4
• Animesh Adult

How quickly Animesh is promoted beyond BlueSteel depends on whether any additional bugs / issues are identified, what else is in the simulator release queue. However, it is unlikely the capability will go grid-wide until the viewer at least reaches release candidate status (at the time of writing, it is still at project viewer status).

No additional bugs have thus far been reported, although there is a claim of slight delays being experienced when starting / stopping Animesh animations.

Vir continues to work on the Animesh viewer’s bugs, which include, but are not limited to:

• Encroachment / Position / Offsets.
• Rigged Mesh Level of Detail / Bounding Box Issues (BUG-214736).
• Broken Rotations Issues.
• 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).

The next viewer Animesh viewer update will likely only be a merge for parity with the updated release viewer; the Animesh viewer update after that should include further fixes / changes.

There’s also more performance and stability testing to be carried out now Animesh is on the main grid and facing some “real” simulator loads, as Aditi is not representative of scripting, etc., loads simulators on Agni have to deal with, or the kind of avatar and rendering loads the viewer has to manage.

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 baking service.

Resources

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

Current Status

There have been some conflicts between Bakes on Mesh and the inventory service. The latter requires an update, but this has been delayed pending updates related to another project (I presume the Environment Enhancement Project, which also requires changes to the inventory system – see below).

It is still not clear if the additional baking channels – LEFT_ARM_TATTOO, LEFT_LEG_TATTOO, AUX1_TATTOO, AUX2_TATTOO and AUX3_TATTOO, which can be access through the latest version of the Bakes on Mesh project viewer (version 5.1.6.516270, dated June 14th, at the time of writing) will be updated to support the application of alpha layers. The con / pro arguments for alpha support on these channels are seen as:

• Against adding alpha support: alphas are primarily a means of masking the system avatar; as these five new channels cannot be used with the system avatar, there is no need to add alpha support.
• For adding alpha support:
  • Regardless of the above, there are cases where creators may want to mask a portion of a mesh on which anyone of these channels are used.
  • Ensuring a consistent means of using alpha masking across all of the bake channels could help in reducing the overall complexity of mesh bodies and heads.

These pro points are being heard by the Lab, and will be discussed further before a final decision is made whether or not to add alpha support to the new channels.

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 God rays.

Resources

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

This work involves simulator and viewer changes, and includes some infrastructure updates.

Current Status

Rider Linden is working on debugging the back-end inventory system changes required to support the new EEP asset types – Sky, Water, Days (as per above). As soon as this work is completed (and presumably passed by QA), thing should be set for a project viewer to be made public, and the back-end support for EEP will be deployed to Aditi for public testing.

The first release of an EEP project viewer will not include any scripting support for the new capability – that will be added as the project viewer iterates. Details of the anticipated scripting support can be found in the project definition document, linked to above.

There was also a short discussion between Vir and Rider Linden on the ease with which sets of assets might be added to the inventory system as a result of Rider’s work.

In Brief

Collaborative Creation

The question was asked if the permissions system in Second Life could be extended to allow easier means of collaborative work.

For example: adding an option to the viewer’s Build floater that allows an item to be shared with the same permissions as granted the creator, or providing a means by which an object’s metadata includes the Agent IDs for avatars with whom it can be shared whilst maintained its original permissions.

There are currently no plans to the Lab to work on the permissions system.

Animesh / Mesh Rotation Issues

There was a discussion during the latter part of the meeting on the mesh / Animesh rotation issues. As noted in previous updates in this blog, there are likely a number of contributing factors to this problem, and the Lab has not settled on a solution.

 

 

 

MindPillars, a Scottish themed Sim – blog post

Updated on June 15th: to include planned RC channel for Animesh deployment – see notes below. 

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, June 14th, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, 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

Current Status

It now appears that Animesh could be arriving on the server-side release channels on the main (SLS) grid as early as week #25 (week commencing Monday, June 18th, 2018). There are caveats to this: the status of issues with the viewer being one of them – there are certain issues the Lab is focused on, which they would ideally like to have some fix / workaround in place for prior to deploying the Animesh simulator code to Agni.

Update: At the TPVD meeting on Friday, June 15th, Oz Linden indicated that if the Animesh simulator code is deployed to an RC in week #25, it will most likely go to BlueSteel.

Current Viewer Issues

Encroachment / Position / Offsets: this is to ensure that the visual position of an Animesh object is not too far offset from its position as calculated by the simulator (e.g. using things like animation offsets to alter the visual position of all or part of an object). The fix for this is to force the bounding boxes for all joints and the meshes attached to them to remain within a specified distance – most likely 3 metres, although this is still TBC – from the location where the simulator has calculated the object should be.

This update should be in the next update to the Animesh project viewer, and will also utilise new infrastructure on the back-end to allow smarter tracking of the bounding boxes for rigged meshes. This be being done by tracking bounding boxes on a per joint basis, and then transforming them. While it can take a “noticeable” mount of time to do this, Vir’s belief is that it doesn’t unduly impact performance, although if it does become an issue, it may be re-thought.

Concerns were expressed that this would limit the scaling of Animesh creations. Vir states this shouldn’t be the case – the restriction is not ties to scale, but to position. So, for example, a dragon could still be 60 metres in length / height,  but the encroachment fix would mean where it appears in people’s viewers cannot be offset more than 10 metres from where the simulator calculates its actual position to be as a static mesh.

Z-Offset Height Setting: until now the z-offset height setting that can be specified when uploading a mesh to Second Life has been ignored when using meshes with it set to Animesh objects (the offset only works when the mesh is attached to and avatar).

It is hoped an update to fix this will be in the next project viewer update, which should appear before the server-side Animesh code arrives on an Agni RC channel.

Rigged Mesh Level of Detail / Bounding Box Issues: (BUG-214736) – Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box.

This is a long-standing issue which Graham and Vir Linden are working on, but a fix is unlikely to be available prior to Animesh arriving on Agni.

Broken Rotations 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.

The recommendation here (for the time being) is that Animesh objects should 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).

Other Issues

Additional bugs: the above are not the only bugs being looked at, but they are the ones causing the most concern due to the risk of behavioural issues / changes they might cause, together with perceived content breakage, when Animesh starts being deployed to the Main grid. Other issues, which are not seen as having so direct an impact will continue to be looked at ad hopefully resolved as Animesh is tested on the Main grid, together with any other issues which may come to light.

GLOD: there is concern that the global LOD values set by the mesh uploader when creators don’t specify their own custom LODs incorrectly encourages poor optimisation, by rewarding those so decrease the calculated LOD values with lower LI post-upload. The feeling is that the reverse should be true. It’s anticipated that Project ARCTan should help to address this.

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 baking service.

Resources

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

Current Status

A new Bakes on Mesh project viewer arrived on Thursday, June 14th. Version 5.1.6.516270 includes the new “universal” wearable types corresponding to the 5 new bake channels. These are:

• LEFT_ARM_TATTOO – bakes to the mesh left arm.
• LEFT_LEG_TATTOO – bakes to the mesh left leg.
• AUX1_TATTOO – creator definable layer / channel.
• AUX2_TATTOO – creator definable layer / channel.
• AUX3_TATTOO – – creator definable layer / channel.

Note that none of these additional wearables can be applied to the system avatar mesh; which continues to use the original six bake channels.

It’s also not clear if alpha layers can mask these new channels at present. If not, that Vir agrees it is something that should be looked at.

Other points of note:

• There are no plans to extend Bake on Mesh to allow the use of wearable on non-wearable objects. This is because Bakes on Mesh uses the avatar bake service, which is not geared to apply wearables to in-world objects sans an avatar shape.
• There is no time frame for Bakes on Mesh deployment at the moment; the project is still in the process of being developed, tested and refined with the help of content creators.
• There is no updated on any form of scripted control for Bakes on Mesh. It hasn’t been ruled out, but no work is currently being done for scripted support.

In Brief

• Mesh uploader cost formula / calculations: there have been requests to offer a clearer explanation of mesh cost calculations through something like a clarified wiki page. In terms of Animesh, providing guidelines on potential cost is difficult, as the actual conversion of a mesh to an Animesh takes place post upload.
  • One suggestion to help estimate Animesh costs is to add an Animesh model type to the drop-down list of object types in the mesh uploader.
• Bento .BVH animation issue: the .BVH format allows for custom joint names for animations in addition to the default joint names. One such custom schema is to prefix joint name with “avatar_”. However, it has recently come to light that while the use of “avatar_” on pre-Bento joints works, trying to upload animations using any of the Bento bones prefixed with “avatar_” results in either an error message on upload (the SL viewer) or the animations uploading, but then being ignored on playback (tested with Firestorm). A JIRA bug report has been requested for this.

Soul2Soul Med – blog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, May 31st, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, 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

Server-side support should now be largely “done”. There remains one issue awaiting resolution. Once this has been cleared, discussions will start on wider deployment of the code – potentially Aditi first, then to an RC channel on Agni (the Main grid). Still no release date due to ongoing work on the viewer.

Rigged Mesh Level of Detail / Bounding Box Issues

(BUG-214736) – Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box.

A new approach to resolving this is being attempted which involves removing non-rigged mesh asset sizes from the rigged mesh bounding box.This will not involve changes to avatar scaling / height calculations. If it works, it should result in better bounding boxes for avatars and rigged mesh attachments in general, not just for Animesh. Currently, it is awaiting some back-end updates.

Avatar Limits and Cost Calculations

These were revised several weeks ago – see the link to Vir’s update in the resources list above – and are unlikely to change. At the previous CCUG meeting, there was some discussion over the streaming cost calculation for the Medium LOD, but again, this will not be changing.

Vir reminded people that the ARC calculation for Animesh is now related to the streaming cost calculation (as per the current project viewer – version 5.1.4.515420 at the time of writing). It therefore shouldn’t be subject to quite the same kinds of issue related to scale-based distortions as previously. It may also go through further tweaks.

On a broader note, costs (streaming, impacts, etc.), are going to be looked at as a part of a separate (to Animesh) project – Project ARCTan – see below.

Broken Rotations Issues

These comprise:

• (BUG-139251), 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.
• 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.

No updates on these were available at the meeting.

Joint Offset Constraint

Setting (either deliberately or accidentally) a bad joint offset with something like the mPelvis bound can result in undesired results. To prevent this, a 5m joint offset constraint was introduced in the project viewer. This has / will be now backed out as it has been seen as overly restrictive. An alternative solution will be sought, and Vir hopes that having a fix for the bounding box issue (above) will help in this.

Animesh and Attachments

There has been confusion over Animesh and attachments. In brief:

• One one Animesh object can be attached to an avatar at a time.
• Animesh objects, while they have a skeleton, do not support avatar-style attachments. Instead, additional objects (e.g. a collar for an Animesh puppy) should be made a part of the Animesh linkset, and then driven by the Animesh skeleton / scripted animations within the Animesh (although objects in n Animesh linkset could be animated by their own scripts / animations if required).
• The above has been discussed at length in previous meetings, due to concerns as to how No Mod Animesh items could be made to work with different options (e.g. a puppy wearing different styles of collar).

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 baking service.

Resources

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

Additional Bake Channels

Anchor Linden has been working to adding five further channels to the Bake Service (left arm, left foot + three additional “general purpose” channels to be defined and used as required by creators). All of these had been intended to be extensions to the tattoo layer. However, in testing, it was found that feeding a wearable layer with these new channels to a viewer without the necessary support to use the channels, the viewer gets “unhappy”.

To avoid this, this Lab has opted to create a new wearable type which will know about these new bake channels. It will sit above the tattoo layer and below the clothing layers.  This should allow those wishing to make use of the new channels to do so without risk of impacting older viewers, which will simply ignore any new wearable layer they’ve not previously encountered. The flip side is, this extends the amount of work required to introduce a new wearable to the inventory service, in additional to the simulator, appearance service and viewer changes already required were the tattoo layer to be used.

A name for the layer has yet to be determined – but “universal” is under consideration – although Rider Linden (with tongue firmly in cheek) suggested “Bob”.

Scripting Support for Bakes On Mesh

No decision on whether this will be addressed, or if it is to be addressed, whether it will be a part of the initial release.

Continue reading “2018 UG updates #22/2: CCUG meeting w/audio” →