You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.
When worn in conjunction with a shape, Shape Override Assets would allow for focused modular adjustments to the avatar shape.
A Shape Overrider is easier to initially visualize from a viewer user interface perspective. With one key difference, the asset's interface would be identical to the current system shape sliders, but there would be a Null Radio Style Button. Initially all the slider values would be set to null, and only if a slider value is input, would that value Override the shape asset value.
Shape Overriders can be stackable. If the first worn override has a value for a specific slider, and a second override is added, then Only the specific slider value of the Last Added Overide is used. My thinking is that this would simplify eliminating some sort of additive effect that could distort system shape mesh beyond it’s parameters.
In order to maintain backward compatibility with system shapes that are used as no modify shape demos, examples being huge hands or feet, Shape Overriders would just fail when used with conjunction with a no mod system shape. This could be visualised by being unable to wear one, or it just not work.
In order to maintain some sort of no mod function when using Shape Overiders, something similar could occur when Overriders are stacked. Either be unable to add an override on top of a no mod Shape Overrider, or Just not have no mod be an option to a shape overrider. If a user feels the need to have a no mod shape override, just provide a no mod shape.
Why is this feature important to you? How would it benefit the community?
Since Shape Overrider are modular, it would dramatically simplify shape adjustments that are used to make specific components ‘look correct’ on current ‘main’ body shape.
One would no longer need to propagate very functional shape changes to all the versions of ones shape.
Because if you buy and playing clothes, this can become… a whole lotta shapes.
For instance:
The more curves, the less curves, the OMG! Curves, the lift the curves, the lower the curves, the tuck in the curves. Spandex is a thing.
Then multiply that by wanting to be the slightly older, really older.
Factor in a shorter for some places, taller for others.
Then multiply again by changing faces too. Not just this or that mesh head, maybe is just lower cheekbones Tuesday?
So some Use Cases:
Changing head. Wear an override. Now can see how you would look with that head configured to fit on the body that you already use.
Changing skin, so need to tweak something.
Changing some curves. Wear an override.
Need to change shape because if it was ‘real’, a mesh clothing would compress or lift something. Wear an override.
Adjusting a couple of sliders to make a standard size mesh fit.
Having a tall and a short. So can kinda fudge getting the animations used by so and so at so and so place, to work 'more righter'.
Changing or Demoing a whatever? Wear an override.
Now, while it won't work 'just right' in every imagined circumstance, it will work a whole lot of the time.
Shape Override / New Asset Type / Avatar Enhancement
Type
New Feature Request
Priority
Unset
Status
Closed
Resolution
Duplicate
Reporter
KathrynLisbeth (kathrynlisbeth)
Created at
2021-07-25T18:37:29Z
Updated at
2021-08-18T13:51:32Z
{
'Build Id': 'unset',
'Business Unit': ['Platform'],
'Date of First Response': '2021-07-26T13:20:30.608-0500',
'How would you like the feature to work?': "When worn in conjunction with a shape, Shape Override Assets would allow for focused modular adjustments to the avatar shape.\r\n\r\nA Shape Overrider is easier to initially visualize from a viewer user interface perspective. With one key difference, the asset's interface would be identical to the current system shape sliders, but there would be a Null Radio Style Button. Initially all the slider values would be set to null, and only if a slider value is input, would that value Override the shape asset value.\r\n\r\nShape Overriders can be stackable. If the first worn override has a value for a specific slider, and a second override is added, then Only the specific slider value of the Last Added Overide is used. My thinking is that this would simplify eliminating some sort of additive effect that could distort system shape mesh beyond it’s parameters.\r\n\r\nIn order to maintain backward compatibility with system shapes that are used as no modify shape demos, examples being huge hands or feet, Shape Overriders would just fail when used with conjunction with a no mod system shape. This could be visualised by being unable to wear one, or it just not work. \r\n\r\nIn order to maintain some sort of no mod function when using Shape Overiders, something similar could occur when Overriders are stacked. Either be unable to add an override on top of a no mod Shape Overrider, or Just not have no mod be an option to a shape overrider. If a user feels the need to have a no mod shape override, just provide a no mod shape. ",
'ReOpened Count': 0.0,
'Severity': 'Unset',
'Target Viewer Version': 'viewer-development',
'Why is this feature important to you? How would it benefit the community?': "Since Shape Overrider are modular, it would dramatically simplify shape adjustments that are used to make specific components ‘look correct’ on current ‘main’ body shape.\r\n\r\nOne would no longer need to propagate very functional shape changes to all the versions of ones shape.\r\n\r\nBecause if you buy and playing clothes, this can become… a whole lotta shapes.\r\n\r\nFor instance:\r\nThe more curves, the less curves, the OMG! Curves, the lift the curves, the lower the curves, the tuck in the curves. Spandex is a thing.\r\nThen multiply that by wanting to be the slightly older, really older.\r\nFactor in a shorter for some places, taller for others.\r\nThen multiply again by changing faces too. Not just this or that mesh head, maybe is just lower cheekbones Tuesday? \r\n\r\n\r\nSo some Use Cases:\r\n1) Changing head. Wear an override. Now can see how you would look with that head configured to fit on the body that you already use. \r\n\r\n2) Changing skin, so need to tweak something.\r\n\r\n2) Changing some curves. Wear an override.\r\n\r\n3) Need to change shape because if it was ‘real’, a mesh clothing would compress or lift something. Wear an override.\r\n\r\n4) Adjusting a couple of sliders to make a standard size mesh fit.\r\n\r\n5) Having a tall and a short. So can kinda fudge getting the animations used by so and so at so and so place, to work 'more righter'. \r\n\r\n6) Changing or Demoing a whatever? Wear an override. \r\n\r\nNow, while it won't work 'just right' in every imagined circumstance, it will work a whole lot of the time.",
}
The text was updated successfully, but these errors were encountered:
How would you like the feature to work?
When worn in conjunction with a shape, Shape Override Assets would allow for focused modular adjustments to the avatar shape.
A Shape Overrider is easier to initially visualize from a viewer user interface perspective. With one key difference, the asset's interface would be identical to the current system shape sliders, but there would be a Null Radio Style Button. Initially all the slider values would be set to null, and only if a slider value is input, would that value Override the shape asset value.
Shape Overriders can be stackable. If the first worn override has a value for a specific slider, and a second override is added, then Only the specific slider value of the Last Added Overide is used. My thinking is that this would simplify eliminating some sort of additive effect that could distort system shape mesh beyond it’s parameters.
In order to maintain backward compatibility with system shapes that are used as no modify shape demos, examples being huge hands or feet, Shape Overriders would just fail when used with conjunction with a no mod system shape. This could be visualised by being unable to wear one, or it just not work.
In order to maintain some sort of no mod function when using Shape Overiders, something similar could occur when Overriders are stacked. Either be unable to add an override on top of a no mod Shape Overrider, or Just not have no mod be an option to a shape overrider. If a user feels the need to have a no mod shape override, just provide a no mod shape.
Why is this feature important to you? How would it benefit the community?
Since Shape Overrider are modular, it would dramatically simplify shape adjustments that are used to make specific components ‘look correct’ on current ‘main’ body shape.
One would no longer need to propagate very functional shape changes to all the versions of ones shape.
Because if you buy and playing clothes, this can become… a whole lotta shapes.
For instance:
The more curves, the less curves, the OMG! Curves, the lift the curves, the lower the curves, the tuck in the curves. Spandex is a thing.
Then multiply that by wanting to be the slightly older, really older.
Factor in a shorter for some places, taller for others.
Then multiply again by changing faces too. Not just this or that mesh head, maybe is just lower cheekbones Tuesday?
So some Use Cases:
Changing head. Wear an override. Now can see how you would look with that head configured to fit on the body that you already use.
Changing skin, so need to tweak something.
Changing some curves. Wear an override.
Need to change shape because if it was ‘real’, a mesh clothing would compress or lift something. Wear an override.
Adjusting a couple of sliders to make a standard size mesh fit.
Having a tall and a short. So can kinda fudge getting the animations used by so and so at so and so place, to work 'more righter'.
Changing or Demoing a whatever? Wear an override.
Now, while it won't work 'just right' in every imagined circumstance, it will work a whole lot of the time.
Links
Related
Original Jira Fields
The text was updated successfully, but these errors were encountered: