Second Life Forums Archive - Animation Reform

Ryoku Itoku

Registered User

Join date: 19 Jan 2006

Posts: 59

05-08-2007 18:53

I’ve found myself many a time deleting my sandbox plywood masterpiece because I’d rather not know how to script movement into a door or move the Lazarus stone every time I come home so I figured it was time to pitch my idea at a feature.

Now I’ve read threw the feature suggestions and found that quite a few animation related improvements have been recommended though they are very loosely composed and only ask for bits and pieces that would solve the problems we have so I came up with a list of things that need improving which are all related under this title.

This is wide open to debate so please feel free to add your comments to the subject and maybe we can get this accomplished with enough support.

From: someone

Grid animation support

1 improve animation support

grid objects animate in a very primitive fashion, with the use of intimidating scripting users can create extremely basic and choppy animations with limited and poor results. There are instances in the grid where a smoother animation becomes more taxing than its alternative due to the amount of effort one must apply to achieve it.

We recommend the use of vector curve animation for objects on the grid, unlike dynamic objects prims with detailed animations usually don’t need to exist physically on the grid instead of programming an object to move in script the use of Key frames on vector curves can create smooth and effect results on simple objects

2 bones and hierarchies

the hierarchy system on the grid and in our inventory is very limited. The bind between two objects is set by distance rather than relationship. Where usually this is good enough it usually becomes very annoying to build some objects to scale or to group complicated objects for packaging or scripting since it requires so many pieces or is overly simplified in the process.

We request better hierarchies.
Under this is the use of bones. Alone bones are basically a prims pivot point which should be adjustable to achieve basic modeling results which currently don’t exist in building techniques past creating unnecessary prims. Bones connected to bones creates a hierarchy [extended group] which should be able to be grouped to other hierarchies to create a “Rig” which can be used to animate off the higher levels.

3 UI animation tools and import/export

With the previously mentioned, the next progression of this process would be to develop a way for users to create and modify animations in the grid. With the ability to create rigs users can modify their avatar or objects threw an easy to understand interface similar to that of Flash or blender or 3ds max and the like. If such tools are outside of the scope of linen labs ability to produce an import export function should be added to use the features so users can edit content externally.

Where linden may not have the resources to develop tools for external applications the dev community has shown its interest in developing other tools, if they are easy to set up and easy to manipulate people will use them.

Hope I don’t sound to forward, just crunching down the original proposition for word count ^^;

Fox Absolute

Registered User

Join date: 30 May 2005

Posts: 75

05-09-2007 05:26

I really think they need to finish implementing avatar animation first. You know, give us the ability to change priority and other settings after we upload, implement a preview model that remotely reflects how the animation will look before we upload, fix how permissions make animations work in gestures and poseballs, etc. At least you can preview images as clothing textures before you upload them. At least you can preview snapshots before you upload them. At least you know a sound is going to be the same in-world as it is when you edit it.

AFAIK, the animation upload process is still the same as when they first implemented it (i.e. borked), and I truthfully believe it is the reason the SL animation business isn't as flourishing and creative as the building and scripting cousins. It doesn't matter how much time and effort you put into making an animation, because there's just no way to tell how it will look in-world until you pay to put it there. The animation business is easily the most expensive, and I usually end up spending up to L$100 on one animation just for tiny tweaks and priority changes.

Draco18s Majestic

Registered User

Join date: 19 Sep 2005

Posts: 2,744

05-09-2007 08:30

Yep yep. Not to mention trying to create animations for a quadrupedal avatar. Sure you can preview the animation, but do the attachments move right?

Ryoku Itoku

Registered User

Join date: 19 Jan 2006

Posts: 59

05-09-2007 10:14

well i think that avatar animation support falls under this anyway so just to get that out of the way. another thing to note is that there is so much that can be asked of animation support, this is just a whish list that covers some of the more basic and in my opinion prominant areas which need to be touched upon.

currently avatars at least have the ability to be developed where as the grid has an indirect form of animation which lacks the same functions as the AV. I think what i'm proposing is simply to level off the animation standard to a place where everything can be improved on instead of just starting.

I understand that existing features are incomplete as they are now and those take priority but all i want people to think of when they read this is to recignize that this needs to be a priority too or at least recignize that this is a notable proplem for the community.

Haravikk Mistral

Registered User

Join date: 8 Oct 2005

Posts: 2,482

05-09-2007 10:47

For in-world objects it would be pretty awesome if we could use .bvh animations to animate individual prims of an entire linked-set. Even if they had to be phantom/non-physical it would be incredibly flexible. Even if it just used the basic avatar 'mannequin' and you had to name objects to correspond with the 'thigh' part of the animation, it could allow you to create robots, NPC 'avatars' and all-sorts. Using a tortured avatar animation you could do some other cool things.

It would basically require nothing more than treating correctly named objects in a set as a single attachment, and moving them with the attachment point the animation creates.

_____________________

Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon
10gb DDR2 800mhz FB-DIMMS
4 x 750gb, 32mb cache hard-drives (RAID-0/striped)
NVidia GeForce 8800GT (512mb)

Ryoku Itoku

Registered User

Join date: 19 Jan 2006

Posts: 59

05-09-2007 20:38

well a rig only has to be as complicated as its parent level objects. strictly speaking animation wouldnt happen on all pieces of a rig just the parent level. for the basic principals and uses that one would need in secondlife for day to day use Forward Kinimatics would be adiquate for average use. (FK is parent child relationships)

a ragdoll only has to be as complicated as the rig or skeleton its bound to, in the case of the feature they are trying to add [AV raggdoll] more than likely they are useing basic prims to fill out the shapes of say the upper arm as a cilinder and a scaled sphere for the head. some pieces dont even need a prim if they wont have collisions, such as the neck or the lower abdomen (dont think about that to hard)

I've worked on enough game mods to know the ins and outs of ragdolls and phys objects.

more or less what i'm saying is that if an animateable object was to exist phisiclay on the grid not every prim in the setup would need to be dynamic just a shell to block objects or act as its animation ragdoll. that or the much similer alternitive of scripting its phantom on and off triggered by the ending of an animation sequence.

EDIT: clearing up some term typos and clearing up some open ended thoughts ^^;

Fox Absolute

Registered User

Join date: 30 May 2005

Posts: 75

05-11-2007 06:48

From: Draco18s Majestic

Yep yep. Not to mention trying to create animations for a quadrupedal avatar. Sure you can preview the animation, but do the attachments move right?

Well an attachment is just an attachment, not an extension of your avatar's skeleton. Even if we could animate objects realistically, you'd still need some form of an "object AO" to coordinate object animations with your avatar's animations, and even then it might get messy due to having to load two or more seperate animations simultaneously.

But yeah, I see no reason why we shouldn't be able to preview animations on our own avatar in-world (at least just rendered client-side only). The animation is already loaded into the client and applied to a model, and it's already possible to view an animation client-side only, so why not just apply the pre-uploaded animation to our real avatar instead of a preview model that doesn't accurately represent any kind of SL avatar at all? At the very least, make the preview model take on our avatar's body shape so we can see how arm/leg lengths and other attributes affect the animation's look.

Draco18s Majestic

Registered User

Join date: 19 Sep 2005

Posts: 2,744

05-11-2007 06:51

From: Fox Absolute

Well an attachment is just an attachment, not an extension of your avatar's skeleton.

...

But yeah, I see no reason why we shouldn't be able to preview animations on our own avatar in-world (at least just rendered client-side only).

That would do what I'm looking for.
I understand that attachments are just attachments, but when you've modeled something like a giant robot, you can't predict how any animation will effect it until AFTER you've paid the L$10

Haravikk Mistral

Registered User

Join date: 8 Oct 2005

Posts: 2,482

05-11-2007 09:11

I currently use the beta grid for this, but I agree, the preview isn't worth it and I go through a ton of L$ just trying to get an animation just right.

_____________________

Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon
10gb DDR2 800mhz FB-DIMMS
4 x 750gb, 32mb cache hard-drives (RAID-0/striped)
NVidia GeForce 8800GT (512mb)

Ryoku Itoku

Registered User

Join date: 19 Jan 2006

Posts: 59

05-14-2007 20:18

From: Fox Absolute

Well an attachment is just an attachment, not an extension of your avatar's skeleton. Even if we could animate objects realistically, you'd still need some form of an "object AO" to coordinate object animations with your avatar's animations, and even then it might get messy due to having to load two or more seperate animations simultaneously.

But yeah, I see no reason why we shouldn't be able to preview animations on our own avatar in-world (at least just rendered client-side only). The animation is already loaded into the client and applied to a model, and it's already possible to view an animation client-side only, so why not just apply the pre-uploaded animation to our real avatar instead of a preview model that doesn't accurately represent any kind of SL avatar at all? At the very least, make the preview model take on our avatar's body shape so we can see how arm/leg lengths and other attributes affect the animation's look.

well speaking from experiance, tandum animations are a bit of a nightmare when done completely isolated from one another however in animation theory it is completley possible to construct a secondary rig to attatch to a point useing the highest level object in the group or hierarchy and animate on top of existing keyframes.

at this point is where the ability to export the rig would come in. instead of ramming the animation process head on inside of second life more advanced users could animate characters and add onto animations externaly and create modular animation sets useing more advanced tools and possibly "baked" physics animations to achive desired results

where the ability may not exisit in SL in any level the ammount of external resoreces are vast enough to achomplish amazing results.

you just need the rite tools.

if the rite processes where demonstrated in animation the biggest possible drawback would be syncing. though syncing is usualy achived with basic playback flags. depending on how its implimented it could be done with scripting or programing. if its programed as such to refere to detailed information such as parrelell keyframes or a loop back start, problem solved.

the last issue would probibly be frame rates. FYI more than likely all SL animations are done at 30fps, setting this up is usualy very easy for external software. just comes down to the knowlege of this little fact. though someone might want to look into that for the sake of clarification.

Animation Reform
Ryoku Itoku Registered User Join date: 19 Jan 2006 Posts: 59	05-08-2007 18:53 I’ve found myself many a time deleting my sandbox plywood masterpiece because I’d rather not know how to script movement into a door or move the Lazarus stone every time I come home so I figured it was time to pitch my idea at a feature. Now I’ve read threw the feature suggestions and found that quite a few animation related improvements have been recommended though they are very loosely composed and only ask for bits and pieces that would solve the problems we have so I came up with a list of things that need improving which are all related under this title. This is wide open to debate so please feel free to add your comments to the subject and maybe we can get this accomplished with enough support. From: someone Grid animation support 1 improve animation support grid objects animate in a very primitive fashion, with the use of intimidating scripting users can create extremely basic and choppy animations with limited and poor results. There are instances in the grid where a smoother animation becomes more taxing than its alternative due to the amount of effort one must apply to achieve it. We recommend the use of vector curve animation for objects on the grid, unlike dynamic objects prims with detailed animations usually don’t need to exist physically on the grid instead of programming an object to move in script the use of Key frames on vector curves can create smooth and effect results on simple objects 2 bones and hierarchies the hierarchy system on the grid and in our inventory is very limited. The bind between two objects is set by distance rather than relationship. Where usually this is good enough it usually becomes very annoying to build some objects to scale or to group complicated objects for packaging or scripting since it requires so many pieces or is overly simplified in the process. We request better hierarchies. Under this is the use of bones. Alone bones are basically a prims pivot point which should be adjustable to achieve basic modeling results which currently don’t exist in building techniques past creating unnecessary prims. Bones connected to bones creates a hierarchy [extended group] which should be able to be grouped to other hierarchies to create a “Rig” which can be used to animate off the higher levels. 3 UI animation tools and import/export With the previously mentioned, the next progression of this process would be to develop a way for users to create and modify animations in the grid. With the ability to create rigs users can modify their avatar or objects threw an easy to understand interface similar to that of Flash or blender or 3ds max and the like. If such tools are outside of the scope of linen labs ability to produce an import export function should be added to use the features so users can edit content externally. Where linden may not have the resources to develop tools for external applications the dev community has shown its interest in developing other tools, if they are easy to set up and easy to manipulate people will use them. Hope I don’t sound to forward, just crunching down the original proposition for word count ^^;
Fox Absolute Registered User Join date: 30 May 2005 Posts: 75	05-09-2007 05:26 I really think they need to finish implementing avatar animation first. You know, give us the ability to change priority and other settings after we upload, implement a preview model that remotely reflects how the animation will look before we upload, fix how permissions make animations work in gestures and poseballs, etc. At least you can preview images as clothing textures before you upload them. At least you can preview snapshots before you upload them. At least you know a sound is going to be the same in-world as it is when you edit it. AFAIK, the animation upload process is still the same as when they first implemented it (i.e. borked), and I truthfully believe it is the reason the SL animation business isn't as flourishing and creative as the building and scripting cousins. It doesn't matter how much time and effort you put into making an animation, because there's just no way to tell how it will look in-world until you pay to put it there. The animation business is easily the most expensive, and I usually end up spending up to L$100 on one animation just for tiny tweaks and priority changes.
Draco18s Majestic Registered User Join date: 19 Sep 2005 Posts: 2,744	05-09-2007 08:30 Yep yep. Not to mention trying to create animations for a quadrupedal avatar. Sure you can preview the animation, but do the attachments move right?
Ryoku Itoku Registered User Join date: 19 Jan 2006 Posts: 59	05-09-2007 10:14 well i think that avatar animation support falls under this anyway so just to get that out of the way. another thing to note is that there is so much that can be asked of animation support, this is just a whish list that covers some of the more basic and in my opinion prominant areas which need to be touched upon. currently avatars at least have the ability to be developed where as the grid has an indirect form of animation which lacks the same functions as the AV. I think what i'm proposing is simply to level off the animation standard to a place where everything can be improved on instead of just starting. I understand that existing features are incomplete as they are now and those take priority but all i want people to think of when they read this is to recignize that this needs to be a priority too or at least recignize that this is a notable proplem for the community.
Haravikk Mistral Registered User Join date: 8 Oct 2005 Posts: 2,482	05-09-2007 10:47 For in-world objects it would be pretty awesome if we could use .bvh animations to animate individual prims of an entire linked-set. Even if they had to be phantom/non-physical it would be incredibly flexible. Even if it just used the basic avatar 'mannequin' and you had to name objects to correspond with the 'thigh' part of the animation, it could allow you to create robots, NPC 'avatars' and all-sorts. Using a tortured avatar animation you could do some other cool things. It would basically require nothing more than treating correctly named objects in a set as a single attachment, and moving them with the attachment point the animation creates. _____________________ Computer (Mac Pro): 2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb)
Ryoku Itoku Registered User Join date: 19 Jan 2006 Posts: 59	05-09-2007 20:38 well a rig only has to be as complicated as its parent level objects. strictly speaking animation wouldnt happen on all pieces of a rig just the parent level. for the basic principals and uses that one would need in secondlife for day to day use Forward Kinimatics would be adiquate for average use. (FK is parent child relationships) a ragdoll only has to be as complicated as the rig or skeleton its bound to, in the case of the feature they are trying to add [AV raggdoll] more than likely they are useing basic prims to fill out the shapes of say the upper arm as a cilinder and a scaled sphere for the head. some pieces dont even need a prim if they wont have collisions, such as the neck or the lower abdomen (dont think about that to hard) I've worked on enough game mods to know the ins and outs of ragdolls and phys objects. more or less what i'm saying is that if an animateable object was to exist phisiclay on the grid not every prim in the setup would need to be dynamic just a shell to block objects or act as its animation ragdoll. that or the much similer alternitive of scripting its phantom on and off triggered by the ending of an animation sequence. EDIT: clearing up some term typos and clearing up some open ended thoughts ^^;
Fox Absolute Registered User Join date: 30 May 2005 Posts: 75	05-11-2007 06:48 From: Draco18s Majestic Yep yep. Not to mention trying to create animations for a quadrupedal avatar. Sure you can preview the animation, but do the attachments move right? Well an attachment is just an attachment, not an extension of your avatar's skeleton. Even if we could animate objects realistically, you'd still need some form of an "object AO" to coordinate object animations with your avatar's animations, and even then it might get messy due to having to load two or more seperate animations simultaneously. But yeah, I see no reason why we shouldn't be able to preview animations on our own avatar in-world (at least just rendered client-side only). The animation is already loaded into the client and applied to a model, and it's already possible to view an animation client-side only, so why not just apply the pre-uploaded animation to our real avatar instead of a preview model that doesn't accurately represent any kind of SL avatar at all? At the very least, make the preview model take on our avatar's body shape so we can see how arm/leg lengths and other attributes affect the animation's look.
Draco18s Majestic Registered User Join date: 19 Sep 2005 Posts: 2,744	05-11-2007 06:51 From: Fox Absolute Well an attachment is just an attachment, not an extension of your avatar's skeleton. ... But yeah, I see no reason why we shouldn't be able to preview animations on our own avatar in-world (at least just rendered client-side only). That would do what I'm looking for. I understand that attachments are just attachments, but when you've modeled something like a giant robot, you can't predict how any animation will effect it until AFTER you've paid the L$10
Haravikk Mistral Registered User Join date: 8 Oct 2005 Posts: 2,482	05-11-2007 09:11 I currently use the beta grid for this, but I agree, the preview isn't worth it and I go through a ton of L$ just trying to get an animation just right. _____________________ Computer (Mac Pro): 2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb)
Ryoku Itoku Registered User Join date: 19 Jan 2006 Posts: 59	05-14-2007 20:18 From: Fox Absolute Well an attachment is just an attachment, not an extension of your avatar's skeleton. Even if we could animate objects realistically, you'd still need some form of an "object AO" to coordinate object animations with your avatar's animations, and even then it might get messy due to having to load two or more seperate animations simultaneously. But yeah, I see no reason why we shouldn't be able to preview animations on our own avatar in-world (at least just rendered client-side only). The animation is already loaded into the client and applied to a model, and it's already possible to view an animation client-side only, so why not just apply the pre-uploaded animation to our real avatar instead of a preview model that doesn't accurately represent any kind of SL avatar at all? At the very least, make the preview model take on our avatar's body shape so we can see how arm/leg lengths and other attributes affect the animation's look. well speaking from experiance, tandum animations are a bit of a nightmare when done completely isolated from one another however in animation theory it is completley possible to construct a secondary rig to attatch to a point useing the highest level object in the group or hierarchy and animate on top of existing keyframes. at this point is where the ability to export the rig would come in. instead of ramming the animation process head on inside of second life more advanced users could animate characters and add onto animations externaly and create modular animation sets useing more advanced tools and possibly "baked" physics animations to achive desired results where the ability may not exisit in SL in any level the ammount of external resoreces are vast enough to achomplish amazing results. you just need the rite tools. if the rite processes where demonstrated in animation the biggest possible drawback would be syncing. though syncing is usualy achived with basic playback flags. depending on how its implimented it could be done with scripting or programing. if its programed as such to refere to detailed information such as parrelell keyframes or a loop back start, problem solved. the last issue would probibly be frame rates. FYI more than likely all SL animations are done at 30fps, setting this up is usualy very easy for external software. just comes down to the knowlege of this little fact. though someone might want to look into that for the sake of clarification.

Welcome to the Second Life Forums Archive

Animation Reform