Day: June 29, 2018

2018 SL UG updates #26/2: CCUG summary

Posted on by Inara Pey

Eri-Ador; Inara Pey, June 2018, on FlickrEri-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

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:
  • 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

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

Current Status

  • Work is progressing on the project viewer, which should be appearing SoonTM – 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.