Any animation requests?

[ger4]

Since I'm learning to animate at the moment, the quality might not be all that great, but if any modders out there want me to try creating any custom animations, I'll give it a go.

 

I'm particularly interested in doing adult animations, but that includes things like kissing/foreplay as well as full on sex.

 

I can create animations using Idle Objects, but not animated idle objects (using blender shapekeys) as when I do that, the animation for the character and animation for the idle object never align in game when they are fine in blender.

 

PS - Just a thought, but how much demand would there be for a modders resource that could always detect if an npc was a companion? I could try and script a user function that recornised all the major companion mods like Share and Recruit, CM Partners and MCS. 

 

Not currently working on anything.

[Badduro NL]

Not an animation on its's own but i would love to see the tongue-bones some people here were working on in "real" action in some of the oral and foreplay animations allready made.

 

 

[rynak777]

The universal companion detect certainly would be useful, but i'm sceptical about how much widespread use it would actually get. Then again, an easy candidate for implementation (proof of concept, kinda) would be the MCS follower HUD.

 

As for animation - i'm not familiar with the technical details, so don't understand the implications of what you wrote. So, i'll just assume it has to do with single actor animations and multi-actor animations (i.e. sex scenes), and then throw in a third thing that apparently is the hardest to do.

 

For single actor animations, i miss a simple and easy to use (interface) plugin, that let's one do just a handful of simple poses. Not a large complex compendium with a slow interface - but instead just simple animations like sitting on the ground and looking around. Basically, very generic and common things for roleplay.

 

For sex stuff - the amount of lovers animations for more "sensual" and "normal" sex are almost zero. Pretty much every animation looks like out of some porn movie. I'm talking about "boring" simple stuff like both lying on top of each other missionary, perhaps initially kissing.

 

As for the apparently hardest thing to do, because the mod itself would have to do all the alignment and positioning ingame, instead of lovers doing that job - people including me have asked for this before, and the answer basically has always been "not planned": An animation and plugin that let's one simply hug or kiss an arbitrary NPC. I know of only two hug mods in existence, and both are very buggy, with one of both coded so obfuscated, that i think it might have been created to enter a competition for the most obfuscated oblivion plugin ever.

 

 

[erc1971]

I would actually like a sensual and slow missionary position animation.  I know it is considered "vanilla", but no animation exists like that right now.  Something with the man atop the woman while they embrace and possibly kiss.

 

Eric

[Contessa]

I'm not sure if it's possible or already exists but I've always wanted a better animation for after sex in Lovers. It's always been kinda funny to me that after I'm done, the parties involved flail around like crazy... hehe. I know it's a default animation but I've always wondered if it's possible to replace just that instance without screwing up other aspects of the game that it was made for.

[ger4]

I would actually like a sensual and slow missionary position animation.  I know it is considered "vanilla", but no animation exists like that right now.  Something with the man atop the woman while they embrace and possibly kiss.

 

Eric

I'll start with Eric's suggestions as its fairly straightforward to do.

 

@Eric - Could you possibily provide so pictures of the kind of thing you want, It will help me get a clearer picture in my head.

 

@Contessa - I could make something like that, but the loverspk scripting doesn't currently support after sex animations, so I don't think it would currently be any use.

 

Cheers.

[yosyoy]

 

I would actually like a sensual and slow missionary position animation.  I know it is considered "vanilla", but no animation exists like that right now.  Something with the man atop the woman while they embrace and possibly kiss.

 

Eric

I'll start with Eric's suggestions as its fairly straightforward to do.

 

@Eric - Could you possibily provide so pictures of the kind of thing you want, It will help me get a clearer picture in my head.

 

@Contessa - I could make something like that, but the loverspk scripting doesn't currently support after sex animations, so I don't think it would currently be any use.

 

Cheers.

 

 

me too...

[woodenstick]

Not sure if it's within the scope of this thread, but I would really love to see a birthing animation for tamago club. Current one is basically having sex with an invisible person you're giving birth to XD

[bp70]

I have an animation that i made a while back that perhaps you'd be able to use to make the sensual missionary position request, or perhaps you could also try and improve on it, since my skills are realy bad.

 

http://www.loverslab.com/topic/18277-lovers-animations-workshop-new-thread/?p=602894

 

that being said, id love to see more body parts grabbing, such as tits, in different animations.

[rynak777]

The problem with grabbing is, that technically, oblivion has no way to let one actor grab a bodypart of another character. Technically, it's all just chars "accidentally" touching each other, if by coincidence choosen body and its variant (i.e. cup-sizes) matches the expectations of the animator. So, whenever you make an animation that requires very precise alignment and body proportions, you're making the animation for a small subset of the players.

[gregathit]

The problem with grabbing is, that technically, oblivion has no way to let one actor grab a bodypart of another character. Technically, it's all just chars "accidentally" touching each other, if by coincidence choosen body and its variant (i.e. cup-sizes) matches the expectations of the animator. So, whenever you make an animation that requires very precise alignment and body proportions, you're making the animation for a small subset of the players.

 

 

Exactly!!!!   When I did the overhaul I purposely moved some of the "grabbing" on tits to other body parts that would be more consistent (neck, arms, shoulders and so on). There are still a few in the LAPF, but it is just a few.  I prefer E or H cup and that is what I make animations based on (the body I use in blender) so anyone "not" using that body would have a wonky animation if I had done a bunch of tit grabbing in the animations.

 

Until someone can figure out a way to have animations be "adaptable" to body sizes this is pretty much not going to happen.  Animators will continue to animate per their "favorite" body type.  Just one of the downsides to an older game unfortunately.

[rynak777]

This is purely hypothetical but - considering what blockhead managed to do with some evil code injection... could an OBSE lib in theory on demand check for location of certain bone nodes, and then pull/push them to a predefined distance? Would the oblivion engine do the rest in terms of kinetics (making the other bones follow suit, ragdoll style)?

 

I'm not familiar with how exactly the LAPF skeleton looks like, but given the support for things like BBB, i imagine there are bones to locate the breasts and their diametre. So, IF the kinetics part were a given, couldn't an injected DLL listen to metadata in animations, and based on them enforce certain distances between bones, across actors?

 

(All of this is just theory - even if it's possible, it still needs someone very talented to code this. Last i checked, the devs responsible for the famous code injections so far, aren't doing adult-focussed hacks : )

[kasimir]

The problem with grabbing is, that technically, oblivion has no way to let one actor grab a bodypart of another character. Technically, it's all just chars "accidentally" touching each other, if by coincidence choosen body and its variant (i.e. cup-sizes) matches the expectations of the animator. So, whenever you make an animation that requires very precise alignment and body proportions, you're making the animation for a small subset of the players.

 

That´s the main reason why I haven´t switched to Skyrim yet.

Over there, it´s even worse and nearly impossible to have a non-clipping animation for 2 different players.

FNIS made some progress, but the core problem will always persist. 

Even if a system to detect this collision or clipping would exist, you would need a system to relocate the bones correctly, which sounds impossible to me, atm.

[gregathit]

This is purely hypothetical but - considering what blockhead managed to do with some evil code injection... could an OBSE lib in theory on demand check for location of certain bone nodes, and then pull/push them to a predefined distance? Would the oblivion engine do the rest in terms of kinetics (making the other bones follow suit, ragdoll style)?

 

I'm not familiar with how exactly the LAPF skeleton looks like, but given the support for things like BBB, i imagine there are bones to locate the breasts and their diametre. So, IF the kinetics part were a given, couldn't an injected DLL listen to metadata in animations, and based on them enforce certain distances between bones, across actors?

 

(All of this is just theory - even if it's possible, it still needs someone very talented to code this. Last i checked, the devs responsible for the famous code injections so far, aren't doing adult-focussed hacks : )

 

Unfortunately this isn't possible right now.  As I understand it blockhead can only switch meshes\textures on the fly which is utterly useless for animations......unless you want your B cup hottie to suddenly have her tits swell to Hcups for the sex act (or vice versa).  

 

The bones have nothing at all to do with size of breast.  The LAPF skeleton is merely Growlf's universal skeleton with penis bones added to it.  That's it.  The skeleton doesn't care if you have Acup or Kcup breasts, it is all the same to it.

 

Bottom line, you'd need to redo the LAPF core programming, redo all animations and figure out how to code for switching stuff out.  All of this is possible..........if you have 2-5 years to wait and can find a group of folks to work on it.  

[rynak777]

I'm sorry, i should have explained better - what i suggested has nothing to do with blockhead. I only mentioned blockhead as an example of how much a little codeinjection (OBSE library) can change the rules.

 

I'll divide my explanation into three seperate problems, which however build on top of each other.

 

____________

 

Problem 1: Measurement

 

I'm not experienced with modelling, but i always imagined that meshes get "rigged" with skels. So, that the ends of bones are tied to certain vertices of the mesh (probably identified by ID or something like that. Or more probably the other way around: Mesh vert references a bone-node by bone ID). If that is the case, then INGAME at *runtime*, a BBB-bone indeed might be used as measuring rod for breast diametre, because ingame, the bone stretches to connect to it's target vert of the mesh. Well, okay not neccessarily... i can imagine some ways to make breasts bounce, without actually putting a bone *through* the breast. So yeah, depends on how BBB is achieved.

 

Anyways, assuming there are bones going through breasts and connecting to one of their surface verts, then code injected at runtime might determine the current location of the bone node - and thus indirectly the approx position/extend of the breast surface mesh.

 

Next, for things like hands there almost certainly are bones going right through them - perhaps even for each individual finger, but that i'm not certain about (maybe it's just one bone for thumb, and another for the other fingers). In any case, locating the hands of another actor via bone node location is a no-brainer, if you can locate bone node locs.

 

If you could follow this far, you'll realize that we now have the position and orientation of the hand of actorA, and the approx surface location and orientation of the breast of actorB. So, we now know where stuff is. What's still missing at this point, is a way to move things.

 

(Small sidenode: All the above work might not actually be neccessary, if we're willing to do a bit of hardcoding: The number of popular body mods and cupsizes is small enough to hardcode offsets into a table - thus, if we can figure out the current body variant of the actors, we can simply read the offsets from a table, without having to measure.)

 

____________________

 

Problem 2: Movement

 

Unfortunatelly, i suspect movement to actually be the hardest - or perhaps impossible - part of the problem. The chain of problems goes like this:

 

1. Can injected code (DLL) modify position of bone nodes at runtime?

 

2. Even if we manage to do that, what about the other connected bones? After all, we want them to follow suit, ragdoll style (kinetics). That is, if we pull the hand to a position, we want the arm to follow. Doing this manually is a mess and way to much work. So the question is: Will the oblivion engine do this automatically for us?

 

________________

 

Problem 3: Control

 

Even given 1. and 2., we of course need a way to send instructions about how we want stuff to move. We'd need a way to send those movement commands. Doing it in the LPK framework itself, is not only way too much work, as you pointed out - it also is a mess, because it would mean that animation descriptions would be split all over the place - some would be in the animation file, others would be in ini files, then other aspects again at another place... bleh.

 

A more clean way would be, if one could embed this extra data, into the animation (.kf) file itself as metadata, so that it would be ignored by oblivion, but interpreted by the injected code. All that LAPF might need to do, is to send to tell the injected code that a given animation should be manipulated, as well as the refs of the affected actors. So, LAPF wouldn't have to handle the manipulation itself - all it would have to do, is inform the injected code when the animations of two actors should be manipulated. The actual movement instructions, the injected code would then read from the .kf metadata.

[gregathit]

I'm sorry, i should have explained better - what i suggested has nothing to do with blockhead. I only mentioned blockhead as an example of how much a little codeinjection (OBSE library) can change the rules.

 

I'll divide my explanation into three seperate problems, which however build on top of each other.

 

____________

 

Problem 1: Measurement

 

I'm not experienced with modelling, but i always imagined that meshes get "rigged" with skels. So, that the ends of bones are tied to certain vertices of the mesh (probably identified by ID or something like that. Or more probably the other way around: Mesh vert references a bone-node by bone ID). If that is the case, then INGAME at *runtime*, a BBB-bone indeed might be used as measuring rod for breast diametre, because ingame, the bone stretches to connect to it's target vert of the mesh. Well, okay not neccessarily... i can imagine some ways to make breasts bounce, without actually putting a bone *through* the breast. So yeah, depends on how BBB is achieved.

 

Anyways, assuming there are bones going through breasts and connecting to one of their surface verts, then code injected at runtime might determine the current location of the bone node - and thus indirectly the approx position/extend of the breast surface mesh.

 

Next, for things like hands there almost certainly are bones going right through them - perhaps even for each individual finger, but that i'm not certain about (maybe it's just one bone for thumb, and another for the other fingers). In any case, locating the hands of another actor via bone node location is a no-brainer, if you can locate bone node locs.

 

If you could follow this far, you'll realize that we now have the position and orientation of the hand of actorA, and the approx surface location and orientation of the breast of actorB. So, we now know where stuff is. What's still missing at this point, is a way to move things.

 

(Small sidenode: All the above work might not actually be neccessary, if we're willing to do a bit of hardcoding: The number of popular body mods and cupsizes is small enough to hardcode offsets into a table - thus, if we can figure out the current body variant of the actors, we can simply read the offsets from a table, without having to measure.)

Doesn't work like that. The bones are the same length for breasts regardless of size. All the vertices of the breasts are tied to particular bones (majority of the tits are tied to breast bone 01 and the areola is tied to breast bone 02 and the nipple is tied to breast bone 03).

 

What you are talking about is "set scale" features and this has been horribly problematic in past attempts. Even trying to implement such a "set scale" feature would require animations be rebuilt as far as I can tell and no one is going to spend the next 9-10 months doing this. Actually the number of different sizes of breasts and shapes is downright rediculous as you can see from the current setbody mod. Not only would you have to jack with breast sizing but body sizing (and shapes) as well.

 

Can it be done....sure. Will it.....no. It would be several years of work by multiple folks to pull it off with the current tools. Now if something new comes out then we can take another look. Until then it just isn't feasible.

 

 

 

 

 

____________________

 

Problem 2: Movement

 

Unfortunatelly, i suspect movement to actually be the hardest - or perhaps impossible - part of the problem. The chain of problems goes like this:

 

1. Can injected code (DLL) modify position of bone nodes at runtime?

 

2. Even if we manage to do that, what about the other connected bones? After all, we want them to follow suit, ragdoll style (kinetics). That is, if we pull the hand to a position, we want the arm to follow. Doing this manually is a mess and way to much work. So the question is: Will the oblivion engine do this automatically for us?

 

 

 

Again, the current tools and systems don't have anything setup for this.

 

 

 

________________

 

Problem 3: Control

 

Even given 1. and 2., we of course need a way to send instructions about how we want stuff to move. We'd need a way to send those movement commands. Doing it in the LPK framework itself, is not only way too much work, as you pointed out - it also is a mess, because it would mean that animation descriptions would be split all over the place - some would be in the animation file, others would be in ini files, then other aspects again at another place... bleh.

 

A more clean way would be, if one could embed this extra data, into the animation (.kf) file itself as metadata, so that it would be ignored by oblivion, but interpreted by the injected code. All that LAPF might need to do, is to send to tell the injected code that a given animation should be manipulated, as well as the refs of the affected actors. So, LAPF wouldn't have to handle the manipulation itself - all it would have to do, is inform the injected code when the animations of two actors should be manipulated. The actual movement instructions, the injected code would then read from the .kf metadata.

 

Embedding something in the animation itself is probably the most practical way to pull this off. Someone would have to invent some way of tying a hand (complete with fingers) to all three breast bones of another NPC to make this work. Again however, with the current tools.....it isn't possible.

 

[rynak777]

Thank you for the explanations, gregathit. I now understand a bit better how oblivion and modelling works.

 

The hardcoding offsets part might be feasible, because setbody tries to support almost every body variant under the sun, but i wasn't proposing this - just the popular ones (i.e., HGEC, DMRA, TGND and one to represent pregnant bodies might be sufficient to cover most players. Supports for others might later perhaps be done via aliases (just mapping them to the most similiar supported body)).

 

But with all the other requirements missing, that's kinda useless, and given the sheer amount of things missing, it's unprobable anyone will do this, even if he/she could. It just isn't worth all the effort.

 

If anything in this direction happens at all, i'd imagine it to be a simple kludge (like, a way for animations to support two variants, and pick one depending on circumstances (this way, the large range of breastsizes could be covered better. Given that we have stuff from A-cup up to luftballons, two arm positions could cover that way better than one).

 

Again, thanks for bothering to explain, even though it has probably been asked plenty of times in the past.

[D_ManXX2]

The problem with grabbing is, that technically, oblivion has no way to let one actor grab a bodypart of another character. Technically, it's all just chars "accidentally" touching each other, if by coincidence choosen body and its variant (i.e. cup-sizes) matches the expectations of the animator. So, whenever you make an animation that requires very precise alignment and body proportions, you're making the animation for a small subset of the players.

 

It is not that it is not impossible but blender 2.49b is pretty crappy and old and does not have the many options newer blender has. you can still create grabbing body part. the real problem is there is too many body parts out there that makes it a real chore to make it compatible.

 

Let say i make bodypart grabbing and use DMRA the breast size is a D-cup now someone uses another body type and has J-cup with is really huge just because it looks good on DMRA it will look terrible on J-cup since oblivion does not use meshes that collides. this way when the breast is bigger the hands will not clip with the breast but actually stay on breast like HDT can now on skyrim.

 

Blender does allow you to grab body parts but you have to be smart and know how to use 2.49b effectively.

[TDA]

I saw (long ago), as one master did  running wagon ((like a car)),  

 

with animation and collisions ...

That's it.

[HyperMix]

Would like to see crawling on all fours for lovers bitch when she has to run towards her master rather than get up and run.

 

Begging with hands held out like paws and she does normal sexy walking move. When she standing still she sits either on her toes upright or squatting, while her hands are still out like paws. Maybe someone will introduced inside slave mod, when slave is hungry or wants attention.

 

 

Not really sex acts just a resource request that I would like to see in mods.

 

Example pics

http://cs.sankakucomplex.com/data/d9/cc/d9cc6813ada4760a3d80fd732c321c33.png

http://cs.sankakucomplex.com/data/d8/5a/d85a3099b0aed48a63ee7f6d6480e705.jpg

 

 

 

 

 

 

[D_ManXX2]

Not sure if skyrim is anything like oblivion if the system are similar then you can still use collision boxes around the body part, and that will solve the clipping issues. that way you can still be able to create breast grabbing and collision to occur once the hand touches the breast mesh par.

 

I have not tried anything like that yet. But it should still be possible.

[The Matrix Prime]

Not sure if anyone is still doing this, but I always thought it was a shame that there were no default female monster and male animations. Oblivion has female monsters such as Spriggans, Flame Atronachs and Spider Daedra, but to my knowledge, nobody ever made sexual animations for them with male PCs or NPCs.

 

Spriggans are humanoid, I'm no animation modder, but you'd think it wouldn't be too hard to get them to use existing female animations. And there are many custom creatures based off the spriggans that should be compatible to with whatever animations were made for them. Nymphs, Naiads, Seducers (made prior to Shivering Isles) just name a few.

 

Flame Atronach might be a little bit harder then spriggans, but they are running around without any pants/thongs on, always seemed like shame that there was nothing any male PC/NPCs could do about it.

 

Spider Daedra ought to be able to give blow jobs, or titty fucks.

[gregathit]

If I ever get un-buried from work adding support for some female creatures will happen with the LAPF.  You can't just "use existing animations" and more than you can piss up a rope.  Animations are made off of the skeleton.  Wrong skeleton and BANG the animation won't work.  Go switching around skeletons and you risk breaking other mods or having them break yours.  You have to either create the animation from scratch or convert it from the human skeleton to the creature one.

 

You can follow along with progress once it restarts here:  http://www.loverslab.com/topic/21315-creatures-overhaul-workshop/

[Oldwolf58]

I may be way off base here but I think, for animations to really go forward, game companies will have to stop using the current Havok collision system and someone will have to come up with a new one. The current collision system in both oblivion and skyrim as well as fallout are made using the havok engine, which is a plugin to the main game engine. To get animations to be able to "grab" certain body parts, for example breast or ass groping the collision would have to be incorporated into the body mesh itself. Havok doesn't do that, it uses collision boxes and or nodes to decide when 2 or more objects are in proximity to each other. If a new system was developed that used the actual object mesh as the collision mesh then things like clothing and groping animations could be done much better. However most game companies won't spend the time to develope a new system to replace havok because the use of the havok system is so wide spread their feelings are that it's good enough and why make a new system when we can save the money and use what everyone else is using. So for all you college guys and gals learning programing who want to make your fortune in the world I have a challenge for you. Develope a new collision system that uses the object mesh as the collision mesh and has a logical weight system based on material type so the gravity works properly. You could make yourself a fortune if you could do it

 

[rynak777]

That would be too slow as the generic system to do collisions. Collision boxes are used for a reason, and the reason isn't just ease of implementation. However, of course collision boxes alone aren't sufficient for all things one might want to do. So ideally, a game would have more than one level of collision detail - collision boxes to do most of the simple things, and as an initial filter (if two boxes don't collide - no need to check the meshes), and then a more complex system to deal with cases where precision and extra features are needed.

 

So, as an example:

 

1. Check giant collision boxes as large as entire meshes, for overlap. If no collision, no need to check further.

2. Use smaller bodypart-sized boxes, to figure out if two parts of a mesh collide. For those that do not, no need to check further.

3. Finally, now that we already know quite well which parts of meshes collide, we can go full detail on just those parts, without having to do such expensive stuff for all meshes in the cell.