Why isn't it possible to move/rotate/scale rigged mesh inworld?

[Sara Nova]

I'm just wondering why this functionality wasn't implemented. It seems like such a simple thing to support, and this is me speaking as a programmer. Just have the viewer transform the vertices of the mesh either before or after applying the skeletal deform, as an extra step when rendering a rigged mesh attachment. Am I missing something and this wouldn't work? Why isn't it a feature?

I'm hoping LL decides to add this. To prevent breaking existing attachments, they could have it be enabled by a setting on the object, which is off by default for older objects, but on by default in newly-uploaded ones. (This could also be where you select whether to apply the transformation before or after the skeletal deform.) Just like positioning and rotation, this could be editable even on no-modify objects, to avoid the side effect of preventing users of older no-modify objects from benefiting from this new way of adjusting fit, in case they're lucky enough that the scale wasn't inadvertently changed by the creator. (In other words, it would keep this backward-compatibility feature from breaking backward-compatibility somewhere else.)

Besides the obvious benefits for adjusting the fit of mesh attachments, this would have other uses as well, such as:

• Making it easier to create rigged items for use with mesh bodies you didn't create, without annoying trial-and-error uploads. (Tip from OptimoMaximo: you can do this trial-and-error testing on the beta grid and you won't waste L$. Thanks again!)
• Rigged attachments that can change size through scripting.

Is this something LL might add in the future? Is it worth submitting as a suggestion?

[Mollymews]

this request has been on the list of nice things that residents would like to have, since mesh was introduced

like you say being able to select an area on a mesh surface on a Modify object and move it, and have the system automagically adjust the weights of worn rigged attachments would be a wonderful thing. Not just for clothing and hair but also for non-rigged inworld mesh objects like trees and bushes. Like just select this tree branch and shorten/lengthen it

i think that Linden would like to do this for us as well, one day some how. It has come up quite a lot over the years.  Like you have here, we just keep on bringing it and keep our fingers crossed and our hopes alive

Edited April 16, 2020 by Mollymews
rigged

[ChinRey]

2 hours ago, Sara Nova said:

I'm just wondering why this functionality wasn't implemented.

It would mean messing around with some seriously messy old code. You have to realize that mesh rigging is not new. Even though it took years before rigged mesh was implemented, the code for it was all incldued in the original 2011 mesh software and like the rest of that code, it's probably full of dodgy quick-and-dirty solutions and questionable priorities. Even Ebbe called it spaghetti code and since you're a programmer, you know that means if you make a tiny change to one part of it you have to expect some other part to collapse.

[Wulfie Reanimator]

What I wonder is how useful would it really be in a lot of cases.

6 hours ago, Sara Nova said:

Making it easier to create rigged items for use with mesh bodies you didn't create, without annoying trial-and-error uploads.

I seriously doubt you could resize mesh by hand accurately enough to make it seamless. There's nothing to snap to, and even the slightest inaccuracy gets worse in altitude.

What about verts around joints? You scale it down and everything starts clipping, you scale it up and you get extreme jaggies.

Do you really get good results when you just scale up the rigged mesh in [insert 3D software]? Genuine question.

[Kyrah Abattoir]

8 hours ago, Sara Nova said:

I'm just wondering why this functionality wasn't implemented. It seems like such a simple thing to support, and this is me speaking as a programmer. Just have the viewer transform the vertices of the mesh either before or after applying the skeletal deform, as an extra step when rendering a rigged mesh attachment. Am I missing something and this wouldn't work? Why isn't it a feature?

I'm hoping LL decides to add this. To prevent breaking existing attachments, they could have it be enabled by a setting on the object, which is off by default for older objects, but on by default in newly-uploaded ones. (This could also be where you select whether to apply the transformation before or after the skeletal deform.) Just like positioning and rotation, this could be editable even on no-modify objects, to avoid the side effect of preventing users of older no-modify objects from benefiting from this new way of adjusting fit, in case they're lucky enough that the scale wasn't inadvertently changed by the creator. (In other words, it would keep this backward-compatibility feature from breaking backward-compatibility somewhere else.)

Besides the obvious benefits for adjusting the fit of mesh attachments, this would have other uses as well, such as:

• Making it easier to create rigged items for use with mesh bodies you didn't create, without annoying trial-and-error uploads. (Tip from OptimoMaximo: you can do this trial-and-error testing on the beta grid and you won't waste L$. Thanks again!)
• Rigged attachments that can change size through scripting.

Is this something LL might add in the future? Is it worth submitting as a suggestion?

Explain to us how this would even work because right now I get the feeling that you don't quite understand what rigging is exactly doing to a mesh.

[Sara Nova]

How what part would work specifically?

[Kyrah Abattoir]

Moving, rotating and scaling rigged meshs.

[Tonk Tomcat]

Rigging = Weights painted on each vertice of an object telling them with what bone they have to move with. So, if you want to rotate and move an object, how should that work? Idk if it's possible to dynamically apply/multiply/some mathematic way of computing the rotation/scale/position to all the vertice weights to have it still move the intended way with the sl skeleton.

[Kyrah Abattoir]

Pretty much @Tonk Tomcat, rigging effectively creates a fixed relationship between the position of each vertex and 1 or more bones of the avatar skeleton.

Fitmesh works by scaling/stretching/moving the bones themselves, causing controlled deformation of the model that is rigged to those bones.

The sum of operations to contort a mesh from its initial shape, to the final stretched, scaled, moved, posed, bent configuration is called a "transform" operation, it is a fairly expensive operation, especially in SL where avatars are composed of up to 38 separate attachments, which can each be composed of hundred of sub parts (pre BoM mesh bodies typically are made of a good hundred sections to be slice-able)

[Mollymews]

4 hours ago, Tonk Tomcat said:

Rigging = Weights painted on each vertice of an object telling them with what bone they have to move with. So, if you want to rotate and move an object, how should that work? Idk if it's possible to dynamically apply/multiply/some mathematic way of computing the rotation/scale/position to all the vertice weights to have it still move the intended way with the sl skeleton.

yes, i agree. Is not a trivial work piece of work this.  Is doable but there is lot that has to go in, to have it be performant in any kind of realtime shared environment like SL

the closest code that came to this as a starting point was the work Qarl Fizz (nee) Linden did back in the day.  Even Qarl said tho that performance issues were a concern. Inworldz did include the Qarl code in their OpenSim world and it kinda worked. After some thought Linden went with the fitted mesh method inspired by redpoly.resident that we have now

if it were ever to be done for SL then most likely it would need a clientside local edit and display window to address the performance issues.  Enter into local editing mode, do the mesh editing then Save. On Save the object edits are uploaded and the edited object then displayed inworld 

[Kyrah Abattoir]

You'd need nothing less than a full blown mesh toolset in-world and then you get the issue of permissions.

[Mollymews]

1 hour ago, Kyrah Abattoir said:

You'd need nothing less than a full blown mesh toolset in-world and then you get the issue of permissions.

is pretty interesting to me this kind of conversation. What could be, what may be, and how might it be done

with permissions then it wouldn't be any different to how it is now. We would need to have Modify permission to edit

i explain a bit how I can see a rigged mesh local editor working. The shape editor is such a local editor. Edit Shape, change our shape parameters as we want in the window/dialog. As we edit the display of changes is only local to us. On Save, our edits are uploaded to the server and made available to others present in the view

looking at it from a Product Director's pov. What single rigged mesh editor capability would my people (residents/customers) want more than any thing else, and on providing this one capability would make them really happy ?

the ability to move a surface area of a garment to prevent body leak. The same capability enabling moving a hair strand out of our ears, away from our chest, away from our body when wearing a coat, closer to our body when not

this only requires an extrusion-like tool that doesn't add or remove vertices. It just moves the existing vertices in the model and re-weights them. The edited/changed weight being calculated as an offset to the existing weight in the model. On Save the calculated weight now being the existing weight for that copy of the model

Edited April 16, 2020 by Mollymews
local

[OptimoMaximo]

On 4/16/2020 at 4:19 PM, Wulfie Reanimator said:

Do you really get good results when you just scale up the rigged mesh in [insert 3D software]? Genuine question

There is a specification to clarify first. 

Mesh objects are made of two levels, the object itself and the child geometry. That is, there is a transform node that acts as a general container for the geometry node, which contains a list of vertices, triangles, vertex and face normals (smoothing groups) , tangents, binormals, material groups etc etc, that make the mesh. Many of these data are ripped off the mesh upon upload and is not included in a SL asset, which instead packs more data in for SL specific purposes (like LoDs). Now, scaling moving and rotate what? The parent transform node? It doesn't end up well and for example in Maya those get locked as soon as an object gets bound to a skeleton. On a geometry node level it is still possible, but again it doesn't always work well without weights rework, indeed geometry animation (blendshapes aka shape keys) does not fare really well along with skeletal animation, if not used carefully it ends in a disaster. See the default avatars surface spikes, stretching, compressions and deformities when animated using extreme shapes.

Now, a skincluster is a list of vertices coordinates relative to the distance from the influencing joint(s) AND the amount of influence such joint(s) have. So it comes by itself that a re computation at render time of all this data that also visually work as well as the original crafted model is not only expensive in terms of computation resources, but a machine can't figure out what "looks right". 

[Kyrah Abattoir]

On 4/17/2020 at 1:47 AM, Mollymews said:

the ability to move a surface area of a garment to prevent body leak. The same capability enabling moving a hair strand out of our ears, away from our chest, away from our body when wearing a coat, closer to our body when not

this only requires an extrusion-like tool that doesn't add or remove vertices. It just moves the existing vertices in the model and re-weights them. The edited/changed weight being calculated as an offset to the existing weight in the model. On Save the calculated weight now being the existing weight for that copy of the model

I get the idea, however there are several problems with moving vertices around:

1. What happens to the normal of that vertex (the normal of a vertex is used for shading the mesh)? creators typically use custom normal orientations to create specific visual effects.
2. Split vertices are used to create uv islands, sharp edges and other useful things. from the point of view of the sl viewers, these vertices effectively are at the same location, but aren't part of the same "mesh", (they are NOT the same vertex), and while a snapping function could be imagined, it is only one part of the problem.
3. Re-weighting: According to what rule?

[Da5id Weatherwax]

I've got to completely go with @Kyrah Abattoir on this one. To do this inworld your edit box would look like Blender. This will never happen, it just isn't practical. The rigging relationship is too complex to allow it to be adjusted with anything simple enough to be an inworld editor.

[Mollymews]

7 hours ago, Kyrah Abattoir said:

I get the idea, however there are several problems with moving vertices around:

1. What happens to the normal of that vertex (the normal of a vertex is used for shading the mesh)? creators typically use custom normal orientations to create specific visual effects.
2. Split vertices are used to create uv islands, sharp edges and other useful things. from the point of view of the sl viewers, these vertices effectively are at the same location, but aren't part of the same "mesh", (they are NOT the same vertex), and while a snapping function could be imagined, it is only one part of the problem.
3. Re-weighting: According to what rule?

yes there are a number of issues to resolve to get such a tool to work

the first is to decide what the purpose of the tool is

the second is to decide how the user would operate the tool

on the first, the purpose is to move vertices on surfaces of a rigged mesh closer to or further away from its origin point(s)

on the second, thinking about it a bit more. In SL a tool that does this already is the land Terraform tool. Set the brush size, strength and direction then drag the brush across the surface(s). Which for the every day user is a relatively simple tool to learn and use

this kind of tool would be a touch up tool. It is not meant to be a fully-fledged sculpting tool. Like the Terraform tool there would be limits on how far we can move vertices from their origin point(s)

the math is a bit more complicated than a terraform tool. In the rigged mesh case there are three things to account for. The bone or bones, the surface's relationship to adjoining surfaces (the edges) and the current weighting of the vertices to the bone(s) before we start editing it. The math to calculate new values from these as our brush moves over them, is not so complicated that it is insurmountable. There are already coded solutions in other mesh creation tools that can do this math

rigged mesh normals could be a issue yes. But I think no more so than the already existing issue when an avatar is animated, stretching and compressing our rigged mesh garment. No more so, as our tool is only repositioning existing vertices. Not adding or removing vertices which could/would break the normal

a thing to consider is that the user will be using their eyes to determine where the surface vertices will be positioned, seeing what effect this might have on the textures, etc. Keep brushing the surface(s) until happy, in the close enough is good enough way. Mess it up, press the Undo Changes button and back to the settings that were in place before edit began

Edited April 22, 2020 by Mollymews
reorder paras

[Kyrah Abattoir]

I'm not a big fan of the terrain editing comparison, mainly because of how simplistic terrain editing is in comparison with tweaking a rigged mesh... I mean, terrain editing is just moving vertices along the Z axis.

Even sculpted prims ended up requiring dedicated tools.

 

We are back at the rigging issue however, as people who started blender trying to make a simple garment can confirm, there is nothing "automatic" about rigging. Auto functions such as weight copy do save a bit of time but they only get you ~50% there.

Edited April 22, 2020 by Kyrah Abattoir