secondlife / jira-archive

2 stars 0 forks source link

[BUG-225161] Creating a (partially) flexible mesh via rigging to an extended skeleton #4030

Open sl-service-account opened 6 years ago

sl-service-account commented 6 years ago

Motivation

Mesh prims have a complex form but by now such a form is not able to move like a regular flexible prim.

You can only imitate flexible moving by rigging the mesh to a skeleton (either of an avatar or animesh character) and animate this skeleton but this movement is fixed: You have to create animations for every needed movement in advance. Also every movement requires actions on the server and data to be sent to clients.

Real flexible prims deform along a flexible path. One end of this path is fixed at the prim position, the other end is free while the path itself deforms in respect of the flexible params applied to the prim. The vertices of the prim reflect then the path deformation. The whole movement is calculated by the viewer and requires neither server-side actions nor any network traffic.

How to implement flexible movement for mesh prims? Apparently it is possible also for mesh prims to go the way of legacy prims: Define a flexible path fixed at the prim position, subdivide the mesh in slides along the path and move the slides in respect of the path deformation. But because the mesh has different forms, I do not expect this approach to always produce an optimal result. However, it can be preferred for an unrigged mesh prim.

Implementation

For a rigged mesh I'd suggest an other way. Such prims already know at least one path: A bone chain. Bones always build chains (be it a single bone) and they can be combined with other chains to a tree structure, called skeleton. The avatar skeleton ("bento" skeleton by the date) is already used for shape sliders and animations so we cannot use it for flexible movement.

What we can do is we create new bones which are not defined by bento, chain the bones and parent them to an appropriate bone of the bento skeleton. The vertices we want to be flexible we rig to these new bones. Now we have a path in our skeleton. The path is given by the chain of the new bones we added. The one end of this path is fixed at the bone position we parented the chain to, and the other end is free. Note, the path is fixed not to the prim center but to the bone of the bento skeleton. Which means than moving the bone via shape sliders or animations will move the fixed end of the new path as well.

I'd call these new bones "flexible bones" and the chain they build the "flexible chain". To avoid things to go too complicated, when we have more than one flexible chain in the same mesh, we do not parent them into a new tree structure, we always parent these chains to any bone of the regular bento skeleton (but we can parent multiple flexible chains foot-by-foot to the same bento bone.)

Now, when the viewer has load the prim and detects this flexible chain, and when the prim is set flexible, the viewer will use this chain as a flexible path: The foot of the chain is fixed at the current position of the parent bone and the chain itself is deformed in respect of the flexible params set to the prim. All vertices that are rigged to the flexible bones will be moved with them as they do when the regular bones are moved – The vertices move now in a real flexible way.

As with the regular flexible prims, the flexible movement is calculated completelly by the viewer, it requires neither actions on the server nor a permanent network traffic.

When there are multiple flexible chains in the same mesh, the viewer will deform them independently but use the same flexible parameters given to the prim. However, I can imagine a new primitive param that controls if multiple flexible chains using the same bento skeleton should move independently or not.

Naming

The names of the flexible bones can be any not defined by bento. In the suggested design, the viewer will use any unknown bone as flexible bone. However, the bento skeleton definition might be extended by new bones in future, which may be used for animating, shape changing or have other roles similar to flexibility definition. Hence, the bone names should follow a naming convention. I would suggest to name the flexible bones by a leading "f" (for "flexible") e.g. "fPigTail_1".

Although its not part of the proposal, when an animation knows names of the flexible bones, it seems to be also able to animate them. This can realize interesting applications but then we need a way to define how the flexible movement should be combined with the animated movement. For example we can use a float primitive parameter where 0.0 means only animated movement, 1.0 means only flexible movement and intermediate values make both overlap with an appropriate weighting.

Applications

The proposed feature allows to create rigid, flexible and mixed rigged meshes in one single pirim. I can think a number of applications which touch quite many residents. Here are few examples.

Clothing

For example skirts and dresses can have flexible parts. To realize them, by now you have to link rigged meshes (rigid by the date) with flexible prims. Rigged parts follow the skeleton, flexible parts not. This means the wearer of the skirt will have to adjust it just to make it look good on their avatar.

After the feature is implemented, the flexible parts will be positioned correctly just because they follow a path that starts at the right bone of the regular skeleton.

Also, you will be able to make a dress having flexible collar, skirt verge and arm sleeves all flapping in the wind while the whole dress would be a single rigged mesh prim.

Flexy hair

The same idea. To create a mesh hair that has flexible parts, by now you have to model the flexible parts via non-rigged flexible prims so the hair will require adjusting sometimes. When the feature is implemented, the whole hair cut will be a single mesh prim, and although rigged it will move in wind or on dance.

Feral avatars

Imagine a mane of a lion. When it has to be flexible, it needs to be non-rigged. After the feature is implemented, the whole lion body inclusive the mane can be a single prim, or at least completely in mesh.

And talking about lions, imagine the brush at the end of the lion's tail. I do not know, today, how to make that part flexible when the tail should be rigged. When the feature is implemented this will be an easy task.

Note and more Applications

There is a small drawback in the suggested approach: The mesh prim has to be rigged in order to have flexible parts. This means only rigged mesh prims that are worn or used as animesh will have flexible parts. Non-rigged will have none, if worn or installed inworld. This is actually not a big problem, because non-rigged mesh prims do not deform, hence flexible prims that are linked to the build can be well-positioned.

However when you teach the viewer to respect flexible bones even when a rigged mesh prim is just rezzed inworld but neither worn nor used as animesh, then you can also create flexible or mixed mesh prims inworld and realize plants, trees, flags, curtains, waves, waterfalls and similar applications.

To do so, you need to create such prims as rigged mesh having flexible bones or even having only flexible bones (bone chains without any bento bone) and rez them inworld instead of wearing. Wearing a mesh rigged to pure flexible bones will make it not deform with the skeleton or animations as if it was not rigged at all.

Links

Related

Original Jira Fields | Field | Value | | ------------- | ------------- | | Issue | BUG-225161 | | Summary | Creating a (partially) flexible mesh via rigging to an extended skeleton | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Jenna Felton (jenna.felton) | | Created at | 2018-07-26T22:13:03Z | | Updated at | 2021-03-06T16:56:36Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2018-08-08T14:31:43.828-0500', 'How would you like the feature to work?': 'A', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'B', } ```
sl-service-account commented 6 years ago

Vir Linden commented at 2018-08-08T19:31:44Z

We've had previous suggestions to enable non-animation control of bones - the is, move bones around under script control. Is there anything that you could do with this proposal that would not be possible with scripted bone controls and a suitably rigged model?

sl-service-account commented 6 years ago

Jenna Felton commented at 2018-08-16T01:42:23Z, updated at 2018-08-16T01:45:12Z

Hello Vir :) Thank you for your request. I am sorry for late response, somehow read your question just now.

I think yes, there is something impossible by scripted bone control.

The proposal tries to define a flexible path, so the viewer knows how it should deform the mesh and what part of the mesh when applying flexible movement: The path is defined by one or more bone chains and only vertices rigged to these bones will move when the path is deformed flexible way. I.E. the viewer itself calculates these deformations without any permanent actions on the server and permanent updates.

Scripted bone control can also emulate that. Here you have to define the flexible deformation by the script, which means you not need to upload tons of animations in order to make the mesh deform in various ways depends on some conditions. But the region server will have to run the script and send updates permanently while the mesh is deforming.

Also the scripted bone control, I believe, will use the already defined bento bones for the flexible movement, while the proposal suggests to add new f-bones to the mesh, so that the skeleton is not affected by the scripted movement. I.e. you can rig the mesh to the whole bento skeleton and still have parts in the mesh that move flexible way.

sl-service-account commented 6 years ago

Fenix Eldritch commented at 2018-08-20T17:55:08Z

Hypothetically speaking, using scripted control to move/rotate rigged bones around in emulation of flexi could probably be done... But it would be very heavy on the server as you'd be doing a lot of llSetLinkPrimitiveParams-like object updates. Not ideal.

However, since the mesh will be suitably rigged in the first place, perhaps we need only have a function to make targeted bones/chains override any animations and behave like flexible paths instead. In theory, you could use a function to apply most of the existing flexi parameters to target bones and the client would take care of the rest as it does today with existing flexi prims.

There is still the matter of new custom bones. I get that the desire is to allow a way to avoid collisions with attachments using repurposed bones on the existing skeleton. But I suspect implementing that has a lot of dependencies or obstacles to tackle first. In lieu of that, I believe having a means of turning existing bones into flexies would be a good starting point.

sl-service-account commented 6 years ago

Vir Linden commented at 2018-08-24T13:23:01Z

Jenna, thanks for the suggestion! Not something we would be prepared to tackle right away, but I'm going to pull this JIRA into the pool of possible future 3D content improvements that we may want to think about.