Category: SL User Group Meetings

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

Animesh Project

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.

Server-Side Updates

Vir believes the Lab is pretty close to a final set of Animesh updates for the server side of things. These include support for the Animesh updated limits and cost formulas, and it is expected that QA will be starting soon on the code in readiness for clearing it for deployment to the Main grid, Agni.

Joint Offset Constraints

One of the reasons the Lab is discussing constraining joint offset is an Animesh bear developed for testing purposes (and which can be found on the Aditi Animesh test regions) which sits some 75 metres off the ground, that’s due to a bad offset being set within the mesh and used with the mPelvis bone, which comes into play when the mesh isn’t being animated.

The bear itself was created as the SL10B wearable avatar, and so demonstrates what can happen with existing wearable content with such errors (which would not become apparent while the mesh is become worn, as the avatar tends to always be in a state of animation) is converted for use as Animesh.

Constraining the distance joints can be offset (say to 5 metres) offers one means of preventing this kind of problem; however, it is recognised that doing so could break existing content – such as the very tall avatar models that are available. Therefore the Lab is considering this an other, more complex options – such as doing something with the bounding box.

Animation Playback Issues

Some are still having Animation playback issues with Animesh objects, notably on initial rezzing or following a region crossing. The advice is it increase the number of animation updates being sent out.

Land Impact

There is some potential confusion with the land impact reports on the mesh uploader and when calculated for an Animesh object when in-world. The uploader calculates the LI for a mesh based on it being a static object. It is only when the object is toggled to Animesh in-world that the revised formulas for LI and complexity are used. This has in turn lead to issues for creators trying to determine what the likely weightings are going to be for their models prior to update.

There have also been some reports that on conversion, models not obeying the new LOD requirements defined as part of the within the new formula suffer heavy penalties when converted to Animesh.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box  (see BUG-214736). Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily.

Graham Linden has been investigating this issue, and now has some updates for the viewer (yet to be integrated with the Animesh project viewer) which should help with this issue and encourage those creator who have, deliberately or accidentally, gaining an advantage from the issue to offers balanced LOD models for their content.

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

Anchor’s most recent work has been:

• Completing the work to implement three more tattoo slots of the Bake Service: skirt tattoo, hair tattoo and eyes tattoo.  These are designed to extend the tattoo to the same set of slots as for the underwear and clothing layers, and hopefully make the available slots far more flexible in potential use when applying baked textures to worn mesh.
• Continuing to work on the skirt layer stacking issue.

The basic functionality of taking system wearable layers and applying them to mesh faces is viewed as working. However, as per my previous Content Creation meeting notes, there is still a lot to be decided on how to progress Bakes on Mesh, particularly in reference to Bakes on Mesh and the applier market, and the overall convenience of Bakes on Mesh for applying textures to worn mesh faces, compared to “ease” of using applier systems for consumers.

Internal discussions about some of the ideas raised around this  – such as being able to inject textures into the Bake Service via script – are still be discussed within the Lab as a result of the concerns raised at the previous CCUG.

Bakes and UV Maps / Spaces

Bakes on Mesh has generated a lot of discussion on the effectiveness of custom UV maps and the Baking Service – UV maps being the thing that take was are essentially 2D textures and “wrap” them around a mesh object. In brief:

• The system avatar has a set of pre-defined UV spaces associated with it. These are used by many of the mesh body makers, and so using system clothing layers via the Bake Service should work on these. Mesh heads tend to be different, and so issues can occur trying to apply skins, etc., to them.
• The Lab’s view is that there’s no reason in principle why the baked textures must use the system UV space. So, for example, and providing none of the system avatar layers (such as the skin) are to be visible, it should be possible to use a set of tattoo layers defined in a specific mesh body’s UV space which can then be passed through the Bake Service and applied to a set of mesh faces regardless of the system UV space.

• An issue here is that only tattoo layers can be used with custom UVs, as all other layers have “holes” in them designed to reveal the system avatar skin, allow for eyelashes, etc.  Therefore, it is not currently possible to re-purpose a shirt layer, for example.  Cathy Foil expanded on this, and on the use of system UV space with mesh bodies.

• Vir expanded a little on the idea that some of the clothing layers that have more “intelligence” built-in (e.g. alpha masking support), hence why they would not work with custom UVs and it would be necessary to use tattoo layers for the textures and re-name them.

Within the meeting, this led to an extended discussion on UV options – such as the advantage of updating the avatar .LAD file and the viewer appearance editor  to allow the use of custom UVs or the system UV space (via an appearance editor check box) over re-purposing tattoo layers.

It’s like that initially, the Lab will lean towards re-purposing tattoo layers, rather than re-working the avatar .LAD and appearance editor, leaving it to body / head creators to offer updated UV maps for those cases where they don’t precisely follow the space UVs.

Next Meeting

There is no CCUG on Thursday, May 3rd due to a conflict with the Lab’s monthly internal meeting. The next CCUG will therefore take place on Thursday, May 1oth, location TBA.

 

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

Medhue Simoni Live streamed the meeting, and his video is embedded at the end of this summary. My thanks to him for providing it. Time stamps are included in the text below to allow easy referencing to the video for details.

Initially, the meeting opened on Aditi at the Animesh test regions.however, Voice issues across the beta grid regions resulted in the meeting decamping to the TPVD amphitheatre on Agni, and these notes reflect the meeting from that point onwards, starting at the 7 minutes 19 seconds point in the video.

Animesh Project

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.

Project Viewer

The project viewer with the updated Animesh land impact / tri count formula was released on Monday, April 16th. Version 5.1.4.514468 also brings the viewer to parity with the current release viewer.

Vir’s provides a detailed explanation in the Animesh updated limits and cost formulas forum thread, However, in summary:

• Animesh attachment limit = 1: only one Animesh object can be attached to an avatar at a time. This is unchanged from the original estimates.
• Triangle Count Limit = 100,000: an animesh object (linkset) can have at most 100k triangles, where the count is based on the estimated size of the largest LOD (normally this is the high LOD). This includes all mesh triangles, static or rigged.
• Land Impact: streaming cost = 15.0 + 1.5 * ktris + cost of non rigged prims: for a rigged mesh prim in an animesh linkset, the streaming cost will be 0.0015 * effective_tri_count – that is, 1.5 per thousand triangles. The value for effective_tri_count is derived from the estimated triangle count of the various LODs in the prim as follows:
  • High LOD: all of the estimated triangle count included in the effective_tri_count.
  • Medium LOD, Low LOD and Lowest LOD: the allowed number of triangles can be up to ½ of the LOD above, or 64, whichever is larger (i.e. Medium can be up to ½ of High, or 64, whichever is larger). If there are more triangles than this limit, that excess will be added to the effective_tri_count.
• These values are also reflected in ARC (avatar rendering cost) calculations for Animesh items.

[7:23-8:43] The viewer also incorporates a change where it will automatically switch to skeleton based rendering for Animesh as soon as it detects the use of an avatar skeleton in an object, rather than waiting until an animation starts playing on an Animesh object in order to make the switch. It is hoped this will avoid issues between an Animesh object’s static and animated states, which can cause visual glitches when the animation based switch is made. It should also avoid potential exploits with people using multiple Animesh objects without necessarily animating them.

[9:13-9:32] It is believed the majority of bugs for Animesh are now in hand, however if any finds specific issues with the new impact calculations or with the latest project viewer in general, they are asked to file a JIRA bug report.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar Bounding Box. Some creators, deliberately or otherwise, force the bounding box to be far larger than is required, which then creates problems

For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily (see BUG-214736 for more).

[8:44-9:12]  Graham Linden has been investigating these, as has some proposed changes which he and Vir hope to implement in the near future, the implication being these will be folded into the Animesh viewer.

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 – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
• Experience-based environment functions
• An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.

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

Current Status

[10:35-11:05] Rider Linden has been involved in dealing with other issues, which have delayed progress on EEP. He hopes that with this worked cleared, he’ll be able to focus on getting the viewer updates out in a project viewer.

Continue reading “2018 SL UG updates #16/2: Content Creator User Group” →