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.
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.
- Animesh User Guide
- Animesh test content
- Animesh LSL methods:
- Animesh – Updated Limits and Cost Formulas
- Animesh feedback thread
- JIRA filter for Animesh
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 188.8.131.525420 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
- (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
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.
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.
This is the code-name for the project to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. As I’ve previously noted, the Lab is sensitive to the implications of doing this – particularly in the area of Land Impact, and will take steps to avoid disruption (e.g. through object returns) once the project reaches that point in time. (One area of potential impact is sculpties, which currently do not have their render cost accurately reflected in their land impact.)
Right now, ARCTan is in its earliest stages, and all that is happening at present is data gathering. No changes to LI, etc., are currently in the works.
Environment Enhancement Project (EEP)
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.
- There are no EEP parameters for manipulating the SL wind.
This work involves simulator and viewer changes, and includes some infrastructure updates.
As part part 1 of this week’s project updates, Rider is still working on a server-side blocker with EEP. Once this has been dealt with, Rider will be able to get the simulator code support for EEP settings to QA. Once the code and the project viewer have cleared QA, the Lab will be able to offer something for people to try out and to to test.
What’s Not On The Table
EEP will not:
- introduce weather systems.
- use the old fluid mechanic clouds are not being re-implemented.
- include reflections.
- manipulate the SL wind in any way.
Prim / Mesh Object Size Limit
Single prim / mesh objects are limited to 64m on a side. Some would like to see this increased to ease the process of making very large (e.g. region-sized) builds (including making them in a 3D tool and uploading them) or in allowing single-piece mesh region surrounds, rather than these having to be created using stacked scuplties. There’s also been requests to increase the distance at which objects can be linked together.
There are currently no plans to change these limits. However, Oz Linden indicated that – and while it is not on the roadmap for implementation this year, his team has started to discuss ways in which region surrounds might be better handled than using the mechanisms that are currently available.
Click Through / Click Action Parameters Feature Requests
Two feature requests have been raised for better support of mouse click operations: BUG-26375, to allow objects (e.g. prim / mesh mist or rain) to be defined as “click-through”, allowing objects within / behind them (such as chairs, etc.) to be clicked on and used. BUG-16339 requests a similar capability, including allowing individual objects in a linkset to be defined as clickable / non-clickable (e.g. so that in a linkset of elevator buttons, the individual floor buttons could be defined as clickable).
During the meeting, Oz noted these ideas may result in the Lab providing a property in the viewer to set the required behaviour, rather than adding LSL functions to support the capability.
I would like it to be true that properties that any built object has that are persistent – unless something is actively changing them – can all be set directly from the viewer, rather than only providing a way to set them by running a script in them. That way [via script] leads to a script being put in them just for setting a property and then has no further use. It would be nice to be able to edit all of those things direct from the viewer, although “all of them” is doubtless something that will take a long time [to achieve].
We’re certainly not going to undo all the things you can currently do with scripting. Those script properties will stay around. And there are lots of cases where object properties where fairly obviously you would want to frequently be able to change, and therefore should be scriptable.
– Oz Linden, CCUG meeting, May 31st, 2018.
There is no meeting on Thursday, June 7th. The next meeting will be at 13:00 SLT on Aditi (Animesh4) on Thursday, June 14th, 2018.