Category: SL User Group Meetings

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, October 26th, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Audio extracts are provided to provide additional content. Note that some of the audio extracts have been gathered from various points in the meeting and presented here as a concatenated whole by subject heading for ease of reference.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “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.

In short, an Animesh object:

• Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Can use many existing animations.

However Animated objects will not (initially):

• Have an avatar shape associated with them
• Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
• Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
• Use the avatar baking service
• Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

General Status

• The project viewer is now available, and testing can be carried out on  5 regions (4 Moderate + 1 Adult) on Aditi: Animesh1, Animesh2, Animesh3, Animesh4 and Animesh Adult.
• Feedback can be offered through the Animesh forum thread, while specific issues, bugs, and / or feature requests related to the project should be made via JIRA.
• A filter for raised JIRA reports is available.

Root Prim Object

There have been a number of requests to allow Animesh objects to have a non-rigged mesh (e.g. a prim) as the root object. Vir has been working to make this possible. He’s also looking at the issue of non-rigged mesh links in an Animesh object becoming invisible when the Animesh flag is set.

Limits

As has been mentioned numerous times in these updates, Animesh will have some constraints / limits placed upon it in the interests of the capability not unduly impacting performance. For the purposes of test, these have been set at 200LI and a maximum of 20K tri maximum per Animesh object, and only one Animesh can be attached to an avatar at a time. As data is gathered on performance, etc., it is hoped these can be relaxed; however, some creators are requesting limits such as the tri count be raised sooner rather than later. Vir, understandably, would rather wait until more data has been gathered, rather than randomly changing constraints.

There has been a proposal for an alternative method of account put forward with regards to Animesh – BUG-139203.  Vir also reiterated the likelihood that the Animesh limits, once finalised, will have a smaller emphasis on constants such as land impact or the cost of having one attached, and a greater emphasis on the complexity of the Animesh itself (tri count).

Linksets / Permissions Issues

See also Piscine Mackenzie’s forum post on this.

As currently defined, Animesh does not allow for any avatar-like attachment  / detachment of objects (e.g., allowing a pet cat to wear a hat sometimes); the approach is more along the lines that everything that is intended to form the Animesh is attached as the time to object (/linkset) is flagged as Animesh.

This is because adding an avatar-like means of supporting attaching / detaching objects was seen as too high an overhead in terms of development time frames and complexity – although it is not entirely ruled out as a possible future capability.

In the meantime, scripted means to attach / detach items from an Animesh object is possible, but this requires the base Animesh to be modifiable. As detailed in Piscine’s post, and highlighted in the following post from Medhue Simoni, this opens the door to potential exploits / threat vectors (e.g. compromising a supporting ecosystem for pets / breedables to the potential for launching DDOS attacks against the external servers managing pets and breedables).

Vir recognises the issue, and has stated he’ll look into the in more detail. One possible solution has been suggested via feature request BUG-139168, and a possible scripted workaround has also been suggested – although it potentially has its own problems.

An offshoot of this is that it could lead to people including multiple accessories within the Animesh linkset. The problems here being a) doing so would immediately require much higher tri counts per object even after the current 20K limit is raised; b) it will require alpha swapping to hide / reveal different accessories, creating performance hits; c) it will limit the ability for new accessories to be easily added to creations.

Sitting Animesh Objects

Will it be easy to have Animesh sit on other objects (e.g. to have Animesh “mannequins” which could be used with demos of furniture so couples poses could be checked by just one person, etc)? Short answer: not easily. Sitting on objects is avatar-specific, which, among other things, involves re-parenting the avatar to the object it is sitting on, and there is no means to replicate this when trying to “sit” an Animesh (which the server sees and just another in-world object) on another object.

In Brief

• Lack of Shadows with Animesh objects: this is a know bug, thought to reside within the rendering pipeline, which has yet to be tracked down.
• Dropping mesh: as noted in my previous CCUG update, by default, mesh attachments cannot be dropped in-world. This means that the only way to currently “pick up” and “put down” an Animesh pet which can roam in-world / be held, is via inventory. Vir has been looking at this, and it is not any easy fix, requiring server-side work (including with physics handling to ensure things land correctly – such as pet on its feet rather than on its side / head) which may preclude it being dealt within the immediate future.

Medhue examines Animesh. Via Medhue Simoni

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. The project is in two phases:

• The current work to update the baking service to support 1024×1024 textures.
• An intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

Load testing with the updated server using 1024×1024 textures is in progress. The next phase is liable to be comparing the load test data with that of an existing baking server using 512×512 textures.

Bakes on Mesh and Animesh

Because of the complexities involved with Bakes on Mesh, it is not seen as a dependency for Animesh, as doing so would greatly extended the time frame for delivering Animesh. The Lab would rather implement both incrementally, rather than try to run everything into one huge project.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.

Current Status

No major change from my previous work. Rider has been working on a simhost issue unrelated to EEP for much of the time.

Final Notes

• Those requiring access to the JIRA to comment on files issues / request, can send an e-mail request to LetMeIn-at-LindenLab.com.
• There is no CCUG meeting on Thursday, November 2nd, 2017. The next meeting will be Thursday, November 9th.

 

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, October 19th, 2017 at 13:00 SLT at the the Hippotropolis Camp Fire Circle. 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 steamed the meeting to You Tube, and his video – in two parts – part 1 and part 2. These have been embedded as a playlist at the end of this article, as should play one to the next. Time stamps to the recordings are included below, and clicking on any of them will launch each video in a separate browser tab at the assigned point. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “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.

In short, an Animesh object:

• Can be any rigged / skinned mesh which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Uses three new LSL methods to run or stop animations, or check which animations are currently running:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Can use many existing animations.

At this point in time, this is not about adding fully functional, avatar-like non-player characters (NPCs) to Second Life. So Animesh objects will not (initially) have an avatar shape associated with them, make use of the viewer’s inventory floater or the server-side avatar locomotion graph for walking, etc., and so will not use an AO, and will not use the avatar baking service. Such capabilities may be added as a future phase of the project.

Viewer Progress

The project viewer, with supporting documentation, was released on Wednesday, October 19th. See the official blog post and my overview for more.

Testing – General Feedback

[video 1: 8:29-9:15] Vir re-iterated that the purpose of the testing is to uncover bugs, check the workflow logic, gather performance data, etc., and encouraged creators to try to push the capability by doing as many different things as possible to ensure this pass of Animesh results in a “good” release.

People have been using the test items provided on Aditi, and early reactions to to the capabilities have been positive. JIRA issues and requests have been filed, and Whirly Fizzle has created a JIRA filter for Animesh to make listing all current reports and requests filed for Animesh.

Some Noted Issues

[Video 1: 10:32-13:15] Animated mesh height placement: One issue with Animesh noted in the meeting is determining where on / above the ground an Animesh objects should be placed, with people noting that when enabling the Animated Mesh option in the viewer, an Animesh creature / avatar can sink into the ground somewhat – as can some Animesh objects which should appear to be attached to an avatar, such as at the hand attachment point.

This appears to be an issue within the baking service which will likely require an update. In addition, Vir is hoping that testing will reveal more about height offset positioning so that the workflow for calculating where Animesh objects appear to be can be further refined to avoid discrepancies.

[Video 1: 16:29-18:18] Animation Playback Speeding Up at Greater Distances: This is a known issue wherein animations appear to “speed up” the further away you cam from the object / avatar being animated (the same thing also happens when avatars are impostered). This isn’t an Animesh issue, but a product of how animation updates are handled and his been known about for some time (and was subject to some investigations and tweaking with things like the Interest list several years ago), and is particularly noticeable with large numbers of avatars dancing.

A non-public JIRA has been specifically filed against the problem for Animesh, as it is felt the problem could be far more visible in regions where Animesh creatures, etc., are used. Vir’s hope is that the Lab can re-examine the issue with a view to reducing the issue’s visibility.

[Video 1: 19:22-19:40] Viewer crashing on unchecking the Animated Mesh option: this is a known issue, but one not seen as occurring frequently enough to be considered a blocker to issuing the test viewer. It is being looked at.

Other Points of Animesh Discussions

• [Video 1: 13:17-15:11]  Animesh: Purpose Built, or Just Conversion? Should Animesh just be a case of being able to convert any rezzable rigged mesh to Animesh (as is the case) or should mesh intended to be Animesh be specifically designed with that end use in mind. In the case of the former, conversion lowers the barrier to entry with Animesh, but might lead to inefficient models being converted, possibly leading to performance issues. The latter is likely to be used by some content creators wishing to optimise their content for Second Life, but potentially limits the scope of Animesh.
• [Video 1: 15:12-16:23] “Unrigging Meshes” on conversion to Animesh: It is noted that converting a rigged mesh to Animesh and not animating it causes the rigging applied to the mesh to be ignored, effectively “converting” it to an unrigged mesh. So modifiable items brought from a creator which are not supplied with an unrigged version might, be “converted” in this way.
• [Video 1: 20:19-21:43] Mesh attach / detach limitations: By default, we generally attach / detach objects directly from inventory; also by default, mesh attachments cannot be dropped in-world. However, this means that the only way to currently “pick up” and “put down” an Animesh pet which can roam in-world / be held, is via inventory, which doesn’t make a lot of visual sense. Vir agrees this should probably be looked at and amended, if possible.
• [Video 1: 22:30-23:12 and 23:40-25:20] 90-degree rotation of visual mesh versus bounding box / physics: The question was asked if this is a side effect of the +x alignment (see my previous CCUG update for a discussion on avatar alignment). In short, yes, but there is a lot going on in defining, rigging, attachment mesh, it’s not clear precisely what is going on, and further investigations are required.
• [Video 2: 0:00-0:30] Attaching a prim object to an Animesh object causes the prim to become invisible: (partially messing from the videos): the reason this happens is unclear, but it is regarded as a bug.
• [Video 2: 0:48-2:15] Is there a script function for attaching a mesh to an existing Animesh object: yes, but is permissions based.
• [Video 2: 3:05-7:45] Facial animation / pathfinding issue? Medhue Simoni reports that adding pathfinding to an Animesh object which does not have facial animations running can make the object’s face “explode”.  This requires further investigation to pin down – but might indicate Animesh may need a “reset” option similar to the Reset Skeleton option for avatars (also covering alignment / bound box issues).
• [Video 2: 7:58-9:45] Animesh and avatar shapes: as noted in the project summary above, Animesh currently does not recognise avatar shapes (but this may be added in a future iteration of the project, once baking service support, etc., is available. This means all joint in a skeleton are in their default position unless affected by a script / animation & there is no ability for shape editing.
• [Video 2: 10:29-13:44 and 15:08-16:00] Sitting on Animesh objects & pathfinding: sitting an avatar on an Animesh object should be possible, but if the mPelvis bone of the Animesh is moving, this may result in odd avatar movements, as noted in past Animesh updates. For an Animesh creature using Pathfinding, a sit target will likely need to be explicitly scripted.
• [Video 2: 14:04-14:29] Interacting with Animesh by clicking on it: there is a known issue still being looked at, where right-clicking on an animated Animesh works, left-clicking doesn’t.
• [Video 2: 16:16-20:00] Using a prim as the root of an Animesh object: Animesh currently requires the root object in the linkset is rigged mesh (and – as noted above, re: attaching prims to an Animesh item) is not very happy if any other parts of the linkset are not rigged mesh. A request has been made to allow the root of Animesh items to be a prim, in order to ease problems of orientation / bounding box scaling.Vir’s view on this is that work still needs to be done to ensure a better placement and orientation of the skeleton in order to better overcome issues of orientation, etc.
• [Video 2: 16:46-17:40 and 22:50-23:20] Handling joint conflicts: conflicts with multiples meshes in an Animesh attempting to manipulate a joint at the same time are essentially handled the same way as for avatars where multiple attachments may try to manipulate the same joint: an arbitrary decision on which position is used is made by the system based on asset UUID.
• [Video 2 20:24- 21:40] Why is there an alignment issue? The core issue with orientation is that, until now, attachments have been based on the avatar skeleton already being in-world, which causes an attachment to be correctly positioned and oriented to it. With Animesh, the opposite is true, it is the object that is already in-world, and the skeleton is then being associated with it. Wherever the skeleton goes and faces will become the visual location / orientation for the object, and its finding a way to most accurately position the skeleton with respect to the object that is the problem.
• [Video 2: 24:40-25:13] Do linked Animesh objects each have a skeleton? No. Animesh linksets only use a single skeleton. So link three Animesh items together, and they’ll have a single skeleton.

Animesh In-World Groups

Two unofficial in-world groups for Animesh have been created:

• Animesh Addicts – created by Chris (Singerman Marquette)
• Animesh Developers – created by Duckie Dickins

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.

Current Status

[Video 2: 25:47-26:38] Rider has converted the day settings in the new format and is about to start working on making environment setting into inventory objects. Once he’s completed this work, his focus will be on producing a project viewer for people to use in testing the available EEP capabilities. This will be “soon”, but may not include the scripted elements of the project.

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. The project is in two phases:

• The current work to update the baking service to support 1024×1024 textures.
• An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

[Video 2: 27:57-28:32] An updated baking service server is going to be set-up on one of the Lab’s internal development grids for load testing.

[Video 2:  28:44-29:33] People are looking towards the bakes on mesh project; Vir re-stated that it is a major project in total, and currently the only aspect being tackled is getting the baking service to comfortably support 1024×0124 textures. Where the rest of the work required to support baking on to mesh bodies and items, etc., lies on the Second Life development roadmap and time frames is still TBD.

Content Creation User Group Meetings Moving to Aditi

[Video 1: 6:44-7:33] To assist with Animesh discussions and testing (the latter of which is currently only be possible on the Aditi, also known as the beta grid or preview grid), CCUG meeting will, for the foreseeable future, be moving to that grid and the Animesh 4 region on Aiditi. Details of the meeting location will be made through the CCUG wiki page.

However, if you have not previously logged-in to Aditi, you will need to file a support ticket to request access, and do so at least 24 hours in advance of the meeting. For further information on Aditi, including how to log-in, please refer to the Aditi wiki page.

 

 

 

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, October 12th, 2017 at 13:00 SLT at the the Hippotropolis Camp Fire Circle. 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 steamed the meeting to You Tube, and his video is embedded at the end of this article, with key points of discussion noted below. Time stamps to the recording are included below, and clicking on any of them will launch the video in a separate browser tab at the assigned point. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “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.

In short, an Animesh object:

• Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Can use many existing animations.

However Animated objects will not (initially):

• Have an avatar shape associated with them
• Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
• Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
• Use the avatar baking service
• Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Viewer Progress

[1:11-3:40] We are now “very close” to seeing a project viewer, test content and test regions appearing. The viewer has been passed by LL’s QA team, the initial test content is being developed (and will be added to, although people can obviously also test their own content) and a total of five regions will be set-up on Aditi (the beta grid) for the purposes of test very soon. Four of these will be arranged in square and be rated Moderate (allowing for comprehensive content testing, including how Animesh is managed on region crossings), the fifth will be separate and rated Adult.

The main hold-up for now is documentation: release notes, wiki documentation, FAQ, etc. When all is ready, there will be a blog post on the project, and the viewer itself will be appearing on the Alternate Viewer wiki page – so those interested in testing Animesh should keep their eyes on both the official blogs and the viewer wiki page.

Root Positioning

[4:20-7:20] The most recent work with Animesh has remained focused on aligning the root joint of a skeleton associated with an Animesh to the position of the Animesh object in-world. The problem here is that the skeleton / avatars in SL are oriented along the X-axis; however, some tools (Avastar?) align along the Y-axis.

This means that when applying skeleton (X-axis orientation) with an in-world mesh objects with a Y-axis orientation to make it Animesh, the latter can jump and rotate. Vir had been looking to make changes in the skeleton’s orientation to handle mesh with a Y-axis orientation this. However, it turns out doing so could cause unwanted behavioural changes for scripts handling attachment rotation and positioning. To avoid this, the skeleton orientation will remaining X-axis oriented. Vir hopes that the upcoming testing will allow the settings for linking skeleton to mesh can be further refined to make the conversion from static mesh to Animesh as smooth as possible.

Animesh and Vehicles / Testing vs Release

[9:20-13:20] A view is expressed that Animesh is being “rushed” without sufficient thought being given to its application in vehicle design. This in part perhaps stems from confusion about public testing of Animesh and a release in Animesh. For example, while Bento had an initial “closed” period of develop to lay the ground work, it was followed by a broad and lengthy public period of testing, consultation and enhancement.

As such, the arrival of the project viewer doesn’t mark a move towards “releasing” Animesh – but rather allows more widespread testing of the capability, including its potential use in vehicles and elsewhere. Testing is the point at which the Lab can more fully look to creators for feedback, requests for improvement – and even fleshed-out feature requests  etc., which might be considered for folding-in to the current work or for follow-on work once the initial Animesh release has been made.

Quick Questions

• Land Impact:
  • [15:54-16:29] Overall land impact constraints of Animesh are still TBD (testing will help determine what might be required). However, Vir points out that in terms of individual LI applied to Animesh objects it will initially be focused on a per skeleton basis, not on a per mesh basis (so a linkset of several rigged meshes converted to Animesh will be seen as single object with an LI, not a group of mesh objects, each with an LI).
  • [37:35-38:34] Couldn’t the Animesh constraint be purely land impact based? possibly, but then attachments would be excluded – as they are with avatars, and the most costly element in terms of performance are avatars; by only using LI as a constraint, then Animesh could become as impactful as avatars with multiple high render cost attachments.
• [16:46-17:18] Is Animesh prim objects with an AO? No. Animesh is rigged mesh objects containing scripted animations within them, associated with an avatar skeleton.
• [17:22-17:57] If an Animesh has linked skeletons, do animations play across all of them? No – Animesh does not involve linking skeletons. It can comprise multiple rigged mesh objects which are linked to an individual skeleton, which can have animations applied to it.
• [18:09-18:30] will the attached mesh also count against the tri count? Yes. There will be a limit, most likely set to 20K when testing starts, but subject to review as testing proceeds.
• [26:02-27:35] Short description of how Animesh will work, as covered in some of the bullet points in the project description, above. Includes some discussion of using Animesh with pathfinding.
• [30:00-30:35] Is animation movement capped (in terms of moving an individual bone): yes, it is capped at 5 metres, as it always has been for avatars.
• [30:41-32:55] Physical properties discussion: Animesh objects will operate like avatars: they well not have physical collisions as a result of animation (e.g. a moving arm on an Animesh will not collide with a passing avatar, for example). However, Animesh objects will have physical properties (based on mesh physics shape), and so can fall, etc.
• [47:35-48:08] Will Animesh alter the land impact for existing objects in-world? No. Animesh is a new object property, only applicable to objects intentionally set as Animesh. As such, it will not affect pre-existing content in-world unless said content is converted to Animesh (if it can be).
• [48:48-49:58] Will Animesh behave at altitude? There  is an issue which sees mesh rigged with software skinning deforms at altitude (starting around 1,000m and getting worse from there). Animesh might suffer the same, but it hasn’t been tested.
• [52:47-56:10] The eyes have it – a discussion on automating eye movements on Animesh in a similar manner to avatars. Vir see this more as building-out the NPC-style capabilities with Animesh, which is very much a follow-up to the current project.
• [58:18-59:20] Can Animesh work with other mesh? It should; the complex part is liable to be keeping the object’s actual position in sync with its rendered position based on the animations playing, particularly as there won’t be a “sit” equivalent. Vir hopes this is something that will be poked at in testing.

Side notes on Animesh Constraints:

[44:08-45:21] As Vir has previously indicated, all of the constraints in the viewer – when it appears – are for testing purposes, and to provide a means by which things can be tested.  For a catch-up on constraints and testing, please refer to my previous CCUG update.

[20:21-20:45] Also, to help with constraints and information, Vir has been updating the viewer’s avatar complexity panel to provide information on triangles, which will also work for Animesh objects.

[22:45-29:08] A feature request has also been submitted for an alternative method of handling land impact and incorporating Animesh – see BUG-139203. This has been left open for comment. However, it is something the Lab is interested in taking a look at.

Continue reading “SL project updates 41/2: Content Creation User Group” →