Uploaded image for project: 'Snowstorm'
  1. Snowstorm
  2. STORM-1964

Feature Request: Animated Rigged Mesh separate of Avatar Skeleton



    • Story
    • Status: Closed
    • Minor
    • Resolution: Won't Finish
    • None
    • None



      The request was prompted by inspecting an animated mesh tail and older prim tail setup and noticing how both use many individual shapes and apply texture and transparent alternately to give the appearance of animation.

      Expected Actions

      It was expected that the new tail would have a system such as internal separately animated bones to allow for a more realistic behavior without the associated issues texture swaps can encounter. 

      Feature Request

      This request is to suggest implementation of rigged meshes set with internal skeletons in a third party 3D creation program and to allow those bones to not be of the body of the avatar, but to be animated separately or to be able to be addressed through script functions directly. Such a feature would reduce lag of certain mesh objects, such as tails, as a single basic script could now control the skeleton of the tail by triggering animations instead of more complex scripts that toggle textures and alphas on complex mesh forms. This would allow improvement in mesh hair, tails, and potentially clothing as they could be set to behave far more realistically while using fewer resources to do so, as they would no longer be dependent on the avatar skeleton and thus behaving in unrealistic way, nor would they be dependent on toggling textures of complex shapes and scripts, and would instead be a singular object that could have exponentially more believable behavior with a reduced sim load. it would also prevent issues where a moment of lag or other graphical glitch causes the texture to not go transparent or a transparent to not get textured, thus chopping up the animation and reducing the level that the tail is believably realistic.
      Many programs can now create animations for any item over a skeleton from rigged mesh objects to the Second Life avatar base skeleton. By using one of these programs, an attachment could be made and animations recorded with it and the avatar skeleton at the same time, allowing the use of a HUD attachment to play the animations as an Animation Override and create natural looking movement of attached items. Because a basic script set and regular animations are used, scripts would not need to control the bones directly, allowing as much of the existing framework as possible to be able to support such a feature as Separately Rigged Attachments without any real notable increase in item impact beyond that of a basic Animation Override for a really advanced worn Separately Rigged item.

      Side Benefits

      The beneficial impact of this change has several notable side benefits. because the attachment is rigged with its own bone system and animated in the conventional manner, the item does not need to be rigged to any part of the avatar skeleton. the first side benefit is a reduced prim count in almost any animated attachment and reduced texture load. Basic animations used allows all existing animated items to naturally animate the avatar, regardless of the worn attachment. The use of a separate rigged attachment also allows all existing items and skins to continue to be fully usable by all residents, regardless of if they use a separate rigged attachment or not. Such separate rigged attachments would also allow creators to build a rigged item as an attachment up to the prim size limit without creating a max prim count tail, allowing more detailed and naturally moving items to exist without the impact of large numbers of primitives, textures, scripts, and memory required for individual pieces. the biggest benefit is that no redesign of the base avatar is ever required. because these attachments are separate of the skeleton, no custom skeleton needs to be created. This means all current skins will be fully usable, all current items and animated items will remain fully usable, and the system will not have to support dozens of different custom skeletons; instead, the separate attachments will function similar to custom animations and avatar skeletons without requiring the massive redesign and the massive obsolescence custom skeletons would require. because all animations, items, and other sold creations would not need any modification due to the lack of any modification to the base avatar, all items remain perfectly usable and all people benefit from having a system giving the benefits of a custom skeleton without a massive redesign of Second Life, presenting a win win scenario for all involved.

      Example 1

      The attached JPEG image of the tail with various highlighted forms is one example of a tail using multiple sections and a toggled texture. It contains several forms for use with sitting, ground sitting, as well as a hug form, in addition to the standing, turning, and forward slithering shapes. Due to the lack of the ability to rig the tail, the tail must consist of multiple sections linked together, all of which need scripts to be able to toggle the texture on the segment, as well as to untoggle the texture and perform the various features. This can result in momentary issues as the new texture loads on the appropriate sections or unloads as the tail moves, occasionally resulting in segments that appear to be floating in the air, unconnected to any other portion. the other issue besides the amount of textures needed and the greatly increased draw weight (and resulting stress on the hardware of other users) is the increased script impact. Each section requires a set of scripts to perform the functions required, and every piece that needs to be able to change the texture has to be able to do so and receive the change command.
      This is where the use of a separately rigged mesh comes into play. The tail could consist of a vastly reduced number of scripts as it would consist of one object, and the script to perform the various animations would either play animations that control the bones and the avatar or the script would animate the bones directly, although animation is likely the most expedient. By using an animation contained in the tail or in a worn AO that has the avatar and tail animation data, the whole avatar and attachment can be fluidly animated at a much lower impact than previously. The reduced number of textures and the complete lack of toggled textures will allow the tail in this example to be animated in a far more fluid manner with a greatly reduced render weight, script count, and memory usage while allowing for a tail that has a more natural look.

      Example 2

      The attached gif image shows the loading of a mesh follower pet. The item is a worn object and is animated to walk when the avatar wearing it walks. This is accomplished currently by having many copies of the mesh load the texture and turn invisible to give the illusion of motion. In this example, a higher level of detail means not all meshes load at the same time and the script is attempting to load the textures on meshes that have not properly rendered. This gives a flickering affect to the mesh that can persist for a notable amount of time until it fully rezzes. The second issue is the stress it places on all video cards of all residents who view it. Due to the large number of meshes that need to load, even when invisible and the textures moving on them puts a substantial load on the video cards. Merely due to the design limitations this object adds roughly 2,000,000 to the draw weight of an avatar. In this case, bones in worn mesh would benefit all residents involved, as the maker would be able to animate it with simple animations instead of dozens of posed models that switch textures, resulting in faster rez times, lower draw weights, and overall better performance for everyone involved with creation, purchase, and viewing.




            Unassigned Unassigned
            nyanyanman nyanyanman
            5 Start watching this issue