2019 Content Creation User Group week #41 summary

Cherishville, August 2019 – blog post

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting, held on Thursday, October 10th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are available on the Content Creation User Group wiki page.

Graphics Team

There are two new Lindens now on the rendering team – Euclid Linden, who has been with the Lab for around a month at the time of writing, and Ptolemy Linden, who has been a Linden for the last couple of weeks, again at the time of writing. Both will be working on various rendering projects which will include the Love Me Render viewer updates and also projects like the Environment Enhancement Project (EEP) – which is considered a priority in order to move that project towards release.

Euclid Linden goes full-on shark-man, while Ptolemy goes a little more conservative with a starter avatar

Viewers

No further updates thus far in the week. The hope is that the Vinsanto Maintenance RC viewer (version 6.3.2.530962 at the time of writing) looks to be in “good shape” for promotion, but currently requires a little more time in its release cohort.

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

  • Current Release version 6.3.1.530559, formerly the Umeshu Maintenance RC viewer, dated, September 5 – No Change.
  • Release channel cohorts:
  • Project viewers:
    • Legacy Profiles viewer, version 6.3.2.530836, September 17. Covers the re-integration of Viewer Profiles.
    • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.530473, September 11.
    • 360 Snapshot project viewer, version 6.2.4.529111, July 16.
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November 2017 – 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.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • Work is progressing on building a predictive model based on the data LL has been gathering on mesh complexity, frame times, etc.
  • This model will be tested across a wider range of client hardware types and different ranges of settings.
  • The data thus far confirms that geometric complexity plays a large part in performance reduction, but also that there are a lot of other variables in play: rigged meshes are very different in behaviour impact to static meshes; some graphics properties can make a “big difference” in frame time, etc.
  • Details on the impact of textures has yet to be folded into the project.

Project Muscadine

Project Summary

Currently: offering the means to change an Animesh size parameters via LSL.

Current Status

Still largely on hold while ARCTan is being focused on.

Other Items in Brief

  • Mesh Uploader: a couple of points were brought up concerning the mesh uploader:
    • At the time mesh was introduced, materials were no supported; therefore, in the uploader there is code to discard tangent space (which can be used by normal maps). This means normals must be calculated in real time, causing both performance problems and inconsistencies between how normals appear in Second Life and how they appear in the 3D software used to create them. It’s been suggested this issue should be the subject of a Jira.
    • Allowing for the work on ARCTan, some see the uploader unfairly punishing on grounds of size and LI.
      • It what pointed out that a very large mesh that can be complex to render get hit with a high LI and high upload cost, but a very small object  – which may still have tens of thousands of triangles – is not penalised to the same degree, even though it might be as costly to render.
      • The alternative suggested was to have costs based not on LOD boundaries & changes rather than a simple size / LI basis. The idea here being that the cost is more reflective of what is seen and rendered by the viewer, which is seen as “levelling” the playing field (if a small object has a really high LOD tri count, then it would incur higher costs, in theory making creators more conservative in how they construct their models.
      • It was pointed out that in some respects complexity / LODs are already being gamed (e.g. by having one high LOD model then setting the medium and low LOD levels to use the same low poly version of the model for both and avoid costs for a proper mid-level LOD model), and such an approach as suggested might further encourage similar gaming.
      • Vir’s view is that the issue is not really that tied to the uploader per se, but is more in the realm of overall cost calculations (although LOD models obviously impact upload costs). As such, ARCTan is really the first step in trying to deal with these kinds of issues, and may help alleviate some of the perceived imbalance seen with upload costs.
  • Materials and Bakes on Mesh: a request was again put forward for LL to provide materials support for Bakes on Mesh. This is not an easy capability to supply, because:
    • System layers for clothing do not have a means to support any materials properties.
    • The Bake Service has no mechanism for identifying and handling materials properties to ensure they are correctly composited.
    • Thus, in order to support materials, both the system wearables and the Bake Service would require a large-scale overhaul which, given all that is going on right now (e.g. trying to transition services to being provisioned via AWS services), the Lab is unwilling to take on.
  • A request was made to allow 2K textures to be displayed by Second Life under “controlled conditions”, the idea being that a single 2K texture could eliminate the need for multiple smaller textures. The two main problems here are:
    • There is already a propensity for people to use high-res textures across all surfaces, whether required or not on the grounds “higher must be visually better”, so allowing even higher resolution textures to be displayed could exacerbate this.
    • Given there is no real gate keeping on how textures are used in-world once uploaded, how would any “controlled conditions” on the use of certain textures actually be implemented (both technically and from a user understanding perspective)?
Advertisements

2019 SL User Groups 39/2: Content Creation summary

Alternate Reality, August 2019 – blog post

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting, held on Thursday, September 26th 2019 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.

This was a shorter than usual meeting.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

Work is continuing on getting the logging and analysis elements of the project up and running. Right now the (in-development) test viewer is described and pouring out a lot of “gibberish” on frame draw rates and all of the attributes in a scene, and the idea is to try to pull this together into a predictive model that is more accurate than the current rendering cost model.

Project Muscadine

Project Summary

Currently: offering the means to change an Animesh size parameters via LSL.

Status

  • Largely on hold while ARCTan is being focused on.
  • A bug whereby physics parameters weren’t being correctly applied has been resolved and a fix should be available in the next viewer update.
    • The default viewer-size avatar animations (fidgets, eye tracking, etc), were disabled for Animesh and have not been re-enabled, this update only applies to physics params.

Environment Enhancement Project

Project Summary

A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • A new graphics resource – Euclid Linden – joined Linden Lab last week. He is currently finding his way around the rendering system and will be working on EEP in the near future.
  • A further graphics expert is due to start with LL in the next month, and once up to speed, they will also be lending support to EEP.

General Notes

  • Script breakage: there have been a number of reports filed concerning script breakage recently (see: BUG-227669BUG-277667 and BUG-227659 for examples). The reports have been noted by the Lab but have yet to be triaged
  • The next CCUG meeting will be on Thursday, October 10th.

2019 SL User Groups 38/2: Content Creation summary

Grauland, July 2019 – blog post

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting, held on Thursday, September 19th 2019 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.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • An unexpected / unintended side-effect of Bakes On Mesh is the baseline avatar rendering cost has gone up by 1,000. This is due to the additional channels being added in support of BOM (so a basic, naked system avatar will have a complexity of 2,000 instead of 1,000). Vir is going to correct this.
  • Just as a reminder: there is no certainty as to how ARCTan will work – the Lab is focused purely on data gathering at this point, not on implementation. As such it is far too early to discuss policy, rules, implementation, etc.
  • One aspect that is being considered is to provide a set of in-world tools and / or example models to allow creators better understand what ARCTan might be doing and how it could affect their work. Again, this could only be done when LL is in a position to start moving forward with ARCTan.

Should Existing In-World Content Be Excluded?

One area of discussion on ARCTan has been the matter of existing in-world content: should it be subject to the new ARCTan calculations (whatever they might be) or excluded?

  • Arguments for excluding existing in-world content include:
    • Less risk of upset if changing values sees an increase in the land impact of items, prompting confusion among users (“why is my 16 LI bed now 26 LI?”).
    • Reduction in the possible large-scale return off objects by parcels / regions where ARCTan changes take them over their limit.
    • “Easier” to implement, as new costs only apply to “new” content.
    • Less work for content creators in updating their documentation (note cards, MP listings, vendor boards, etc.) to correctly reflect the “new” LI values for their goods that are changed as a result of ARCTan.
    • Reduces the risk of “permanent” content breakage in instances where the LI for objects rises to impact user’s ability to have them in-world, and the creator is no longer active to provide better optimised updates.
  • Arguments against excluding existing in-world content include:
    • Potentially limits the purpose of ARCTan in educating users about using decently optimised content.
    • Introduces questions on how new limited should be applied. On upload? On rezzing?
    • If on rezzing, user confusion may not be negated (“when I rezzed this bed last week it was only 16 LI; now when I rez it, it is 26 LI! Why?!)
    • ARCTan will not be an overnight implementation. LL plan to try to work with creators and users to provided information on changes, and work as far as possible to minimise the risk of content return.
  • The idea of excluding existing content has not been ruled out. But again, until the Lab have baselined their data, carried out experiments and tests in order to see the likely impact of various adjustments to the calculations / costs and investigated what can be done to mitigate some of them (e.g. increase the land capacity of regions), nothing can be decided one way or the other.

Core Content Projects Summary

  • Animesh Follow-On – Project Muscadine: effectively on hold while Vir focuses on ARCTan.
  • EEP: work continuing on rendering bug fixes, with additional resources being added to the project.

General Notes

  • Avatar Impostering
    • Concern has been raised over the complexity handling on Animesh with impostering. Currently, Animesh objects are handled the same as avatars. However, as they are a lot less complex, there is an argument to say Animesh should be handled differently to avatars when impostering.
    • This is being taken into consideration, with the possible introduction of a “max Animesh” setting for the purposes of impostering Animesh.
    • Whether or not this will affect the current baseline for impostering avatars is unclear; the work is still only at the point of discussion.
  • Mesh uploader:
    • There are reports of a rise in issues when uploading mesh models – failure to complete the upload, coupled with the production of hard-to-decipher “mav” errors.
      • So far as the Lab is aware, nothing has changed within the viewer or on the simulator side that might be causing the problems. Those encountering such problems are asked to file a Jira, preferably with  viewer log files.
      • There is a viewer with improvements to the mesh uploader in development. This may not resolve the issues, but it should offer improved feedback and messaging during the upload process.
      • It’s been suggested that the problem could be due to recent updates to Blender in saving .DAE files.
    • Many 3D tools are moving to use / support the glTF file format, which is currently subject to much discussion / criticism. Linden Lab has no plans to support the format at this point in time.
    • A few months ago, it was indicated that custom origin point (pivot point) for meshes would be implemented. This work is currently awaiting some back-end changes. As such, until these changes are made, the work is on hold.

2019 SL User Groups 37/2: Content Creation summary

Athenaeum, July 2019 – blog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, September 12th 2019 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 Follow-On – Project Muscadine

Project Summary

Currently: offer the means to change an Animesh size parameters via LSL.

Current Status

  • The viewer updated to version 6.4.0.530473 on Wednesday, September 11th – however, this is to parity with the EEP RC viewer, rather than any new features being added.
  • Viewer work is currently on the back-burner for now, while Vir is working on ARCTan. As such, it’s likely that the project will proceed with small updates  – such as those in the current project viewer – rather than gathering together a larger number of updates and releasing them together.
  • A potential update still under consideration is to revise the current throttle (limiting Animesh character to updating twice every 10 seconds). This was put in place to prevent people using the system as an alternative means of animation (and potentially thrashing performance)s.
    • Some have done informal testing with up to 20 Animesh characters changing shape under scripted control as fast as the current throttle allows and using 115 parameters, apparently with little performance impact.
  • Animesh objects currently count towards the overall avatar imposter limit – although it is possible these might be split.
    • The “pro” side of this is that Animesh objects have a fairly fixed rendering complexity.
    • The “con” side is how things might change if Animesh characters start having attachments.
    • It would also mean further complexity with graphics settings in the viewer.

Environment Enhancement Project

Project Summary

A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • Work continues on rendering bug fixes.
  • There is still no indication as to when this might be promoted to release status.
  • A lot of EEP documentation is currently in the forum threads. There has been a request to move this to the wiki – or at least is the Knowledge Base, which is current a focus for documentation from the Lab.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • Progress has now resumed, with Vir working on hooking new data gathering code into the viewer code base to allow more widespread data gathering.
  • The code currently isn’t available in a public viewer repository (in part because it is not ready).
  • It has been suggested that allowing Firestorm to use the code would potentially allow for a broader cross-section of representative data to be gathered. However, the core data gathering code is baked into viewer, and making that alone available for FS to adopt at this point in time could be difficult.
  • There are concerns that major changes in the costs of in-world objects could see an increase in Land Impact values that could in turn see large amounts of content returned.
    • This is something the Lab is concerned about as well, and it has previously been indicated that if this proves to be a significant risk, then steps will be taken to mitigate this – see Project ARCTan in 2018 SL UG updates #7/3: TPV and Web Meetings.
    • It’s been suggested that ARCTan could offer a new “invisible” mesh asset type: anything that is created uploaded after ARCTan is (eventually) deployed must conform to ARCTan; mesh in-world prior to ARCTan is not governed by ARCTan – as was done with Materials. Vir indicated this might be one option, at least during the initial roll-out of ARCTan.
  • There is a lot of chatter / speculation in the forums about what ARCTan “might” or “will” be; Vir’s response to this is again that no decisions have thus far been made by the Lab as the project is still in its early stages. Therefore, people should not put too much stock in forum thread unless it is posted by the Lab.
  • It’s important to note that beyond data gathering, LL haven’t even decided how ambitious the project will be overall.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos and clothing) to be applied directly to mesh bodies and heads.

Resources

Current Status

  • There has been extensive discussion on Bakes on Mesh in the forums, including ideas on future extensions, some of which are being pulled in by the Lab for additional consideration (which is not to say they will happen).
  • There is an unofficial list for BoM support (last updated at the end of August) which may help those interested.
  • Cathy Foil has been investigating the local edit issue she reported at the last meeting (see:) wherein odd results when using the appearance editor that correct themselves on exiting the appearance editor and when baked via the Baking Service. In her case, it appears the problem was due to a slip-up at her end of things involving a mesh with different UVs, although a Jira has been filed on a related issue.
  • There is a report that eye textures applied via BoM appear darker than if applied directly to the mesh. A Bug report is to be raised on this.

2019 SL User Groups 35/2: Content Creation summary

(fae forest), July 2019 – blog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, August 29th 2019 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.

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 and heads. This involves viewer and server-side changes, including updating the Bake Service to support 1024×1024 textures, but does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.

Resources

Current Status

  • BoM is now live. See:
  • There are some local edit issues  – some already noted in the viewer release notes – that can produce odd results when using the appearance editor which correct themselves on exiting the appearance editor and when baked via the Baking Service.
Cathy Foil has noted this glitch than can occur with Baked_Lower wearables on BOM: when editing locally in the appearance editor, the leg does not appear to be masked correctly by the wearable (which is also incomplete at the waist). Once baked, however, the wearable appears correctly applied and in full (r). Credit: Cathy Foil.
  • Some of these local edit issues may not be specific to Bakes on Mesh, but may be more noticeable as a result of BoM, and the Lab is looking to resolve them.

Animesh Follow-On – Project Muscatene

Project Summary

Currently: offer the means to change an Animesh size parameters via LSL.

Current Status

  • The simulator support on Aditi (the beta grid) – DRTSIM-421 (region Bakes on Mesh) has been updated, but there are no feature changes within it.
  • The project viewer has been merged with Bakes on Mesh (as the release viewer) and is passing through the Lab’s QA, and so should be appearing soon.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • Work has now resumed.
  • First part of this is to continue data-gathering and look at re-aligning some figures based on the changes made for Animesh.
  • Thus far, the project primarily comprises enhanced logging to assist the Lab in data collection, allowing information on the overall cost of a specific avatar or in-world object to be gathered.
  • Once enough data has been gathered across a broader enough spectrum of content to give the Lab confidence they have a good understanding of things, then work can start on adjusting the cost calculations for rendering, etc.
  • It’s important to note that any user-viewable changes as a result of ARCTan are still some way off, and the Lab will be staging things to let users know what is happening when, and what it is likely to impact.
  • There was a lot of general conversation towards the end of the meeting on what people hope ARCTan will do (e.g. forcing creators to make proper use of avatar LODs, etc.).

Environment Enhancement Project

Project Summary

A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • Work continues on rendering bug fixes.
  • The number of remaining issues is “trending downwards”.

Misc. Items

  • The upcoming Voice RC (or project) viewer mentioned at the last TPVD meeting still has a couple of issues preventing it from surfacing in the Alternative Viewers page.
  • The Umeshu Maintenance viewer (currently version 6.3.1.530411, merged with Bakes on Mesh) could be promoted to de facto release status as early as week #36 (commencing Monday, September 2nd), in a break from the Lab’s preferred 2-week gap between release promotions.
  • Date of next meeting: Thursday, September 12th, 2019.

 

2019 SL User Groups 34/2: Content Creation summary

Scarlett Isle; Inara Pey, July 2019, on FlickrScarlett Isle, blog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, August 22nd 2019 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.

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 Bake Service to support 1024×1024 textures, but does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.

Resources

Current Status

  • An internal meeting at the Lab held immediately prior to the CCUG suggests Bakes on Mesh could be promoted to release status early in week #35 (week commencing Monday, August 26th, 2019).
  • It was therefore requested than anyone intending to test BoM to do so over the weekend and file any issues they find via Jira bug reports ASAP.
  • There are some known issues that will be listed when the project is promoted to release status, and which will be noted in the Bakes on Mesh knowledge base article when BoM is promoted to release status.
  • The major element in understanding how BoM works is understanding how the additional channels supplied for Bakes on Mesh work. These are:
    • LEFT_ARM_TATTOO – baked to left arm.
    • LEFT_LEG_TATTOO – baked to left leg.
    • AUX1_TATTOO – baked to aux1.
    • AUX2_TATTOO – baked to aux2.
    • AUX3_TATTOO – baked to aux3.
  • Unlike the existing channels (head, upper, lower, etc)., these do not have an underlying skin texture associated with them, and so do not have a wearable corresponding to the alpha wearable that can be used with the existing channels to “hide” them.
    • This may be changed in a future update, but for now, it is how Bakes on Mesh will be shipped with the new channels.

Environment Enhancement Project

Project Summary

A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • Work continues on rendering bug fixes.
  • There are also some permissions bugs that need to be resolved as well.
  • Overall, it is hoped that these can be resolved and the viewer updated soon, with a view to moving EEP on to release status in the near future.

Animesh Follow-On – Project Muscadine

  • DRTSIM-421 on Aditi (region Bakes on Mesh) has the server-side code to support the new visual parameters LSL code.
  • The project viewer is now available – viewer version 6.4.0.530100, dated Monday, August 19th. This supports the new LSL code as per DRTSIM-421, above.
  • Vir has other commitments coming up (ARCTan?), so progress on updates to this work may be slow for the next several weeks.
  • A potential update is to revise the current throttle (limiting Animesh character to updating twice every 10 seconds). This was put in place to prevent people using the system as an alternative means of animation (and potentially thrashing performance); however, it is considered too slow for testing purposes.

Bakes on Mesh for Animesh

Still being requested, but also still seen as a significant piece of work, as it would require changes not just with how Animesh items are managed but to the entire Bake Service in support of the capability. As such, this is not currently something the Lab is putting on the road map.

Animesh Attachments

Having attach point for Animesh characters and items is seen by come as a higher priority than extending Bakes on Mesh to Animesh. It is also something the Lab could implement somewhat more easily (for some value of “easily” to be determined) than BoM on Animesh. A call was made for possible use-cases included particle support, ability to simple attach clothing items rather than having to rig them (which would conversely limit movement of the item as it wouldn’t necessarily conform to the Animesh body movements), objects such as weapons (for NPCs), etc.