Jump to content

Any animation requests?


ger4

Recommended Posts

The Nif format has a flag for collision detection type since at least 4.0.0.2 (Nifscope: select an NiTristrip/NiTrishape and examine the flags. See the collision detection options? Triangles!) (DON'T change it, you'll break the mesh at best).

 

Honestly guys and gals, it isn't a simple as you think and Beth are notably bad at using Gaming Toolkits and SDKs.

Link to comment

@Symon & rynak777: Yes nif does have collision flags and blender also has the capability of using the object mesh as a collision mesh but the GAME itself doesn't recognize nor utilize those abilities becausse the HAVOK system ignores them. To get proper movement of things like loose clothing draping properly on a body mesh a new system is needed that will replace the current Havok based system. Havok has been around for nearly 15 years now and yes they do have plugin peices that do better physics for collision all the way down to clothing, the problem is none of the current games are utilizing those plugins. It's quite possible that if the complete havok system was employed by a game you could have some truely stupendous animations and believably realistic clothing BUT until a game comes out that has the various Havok plugins installed and utilized we're stuck with a system that can't do what we modders can envision. That's the problem and if someone could come up with a better collision system that didn't cause image stuttering when two items were in close proximity (even touching like clothing on a body) they would be able to make a fortune off of it.

 

and rynak, that thinking is exactly why you get rained on in both oblivion and skyrim when standing on a porch under the porch roof, or while standing under a bridge. Nor do you see water running off your body or the roofs of buildings during a rain storm. These things can be addressed and fixed (there is a mod to prevent the thru the roof rain effect for skyrim). Todays rigs and video cards are capable of handling this and more but as I said before the game companies are using the least they can to get a reasonable look to the game and the hell with making the environment look as real as possible let alone the clothing. With that thinking we as modders will NEVER be able to make the animations and additions to the games to make them as realistic as we'd like to see them.

Link to comment

I've always wondered how the animations in 3d hentai formats are done. They are often far ahead of what we are capable to achieve for TES games. 

They are probably not bound to some skeletons like our animations are.

Link to comment

I hate to say this but even if todays rigs can handle them, it is the game engine that holding everything back. and we all know how poorly Bethesda is known to optimize there engine. so to many things collide and the poor engine will snap. you already see it with hdt if too many npc get to close and your game will suffer. Btw that is skyrim Oblivion engine is even worse.

Link to comment

Another issue with the "but we now have the powah"-mantra is, that this way, truely new things don't become possible. You just end up doing the same old stuff more high-def, because the moment more proc power becomes available, it used up right away for upping detail or lazier programming. This is especially disgusting, for open-world games like TES or GTA. Those game still use reallly really sad techniques to keep ressource usage down, in ways that go straight against the idea of open world games. Drawing distance and ped limits in GTA anyone? Machines become ever more powerful, and yet we get just the same old games with the same old scales and bottlenecks - BUT lookie, now they look more fancy! The ultimate punch to the gamer's face must by GTAV physics.... which are worse than GTASA.... terrain often doesn't even have frigging DIAGONALS.... ramps and stairs are handled like boxes, BUT everything is now textured in HD! Progress!

 

Anyways, what i'm saying is - the whole "but we COULD now entirely operate on meshes - death to the boxes!" idea strangely reminds me of Carmacks attitude, when he said "Let's just raycast everything!". Completely ridiculous and wasteful to me.... and unneccessary.

 

See, even if you want to do such neat tricks with clothing.... or rain... then you can use boxes to quickly exclude all the things that couldn't possibly collide. For those that could possibly collide, you then use mesh based physics. Results will be the same, but you will have saved ressources - ressources which you then can use to do new interesting things.

Link to comment

@rynak777, I'm not saying get rid of collision boxes, nor am I saying the ONLY problem is the Havok system, what I am saying is that a better system can and should be developed. Havok is moving in that direction by releasing plugins to address their short comings. These "plugins" have to be incorporated into and utilized by the game engine itself to be effective and imho plugins are like patches, they rarely work as well as they should. It would be better to devise a new system that addresses the issues right from the beginning. Perhaps that means a new game engine that instead of using havok as a plugin instead incorporates a gravity collision system in the engine itself.

 

Ever killed an enemy in oblivion and then been unable to find the weapon or shield or even the NPC because they fell through the ground? That's the type of thing that should have addressed right from the start by the game engine / collision system and isn't because it was left up to a plugin (the Havok system) to address and with the shoddy meshes used for the ground and floors and walls etc. things just fall through instead of coming to rest on top of them. Until that type of issue is addressed and resolved and a universal weighting system within the game is used to ensure that water acts like water when encountering a heavier weighted object (strikes roof and follows the contour of said roof) then we will always have the same problem reguardless of the game we play.

Link to comment

@oldwolf:

I'm sorry, i misunderstood you then. I completely agree with what you wrote in your above post.

 

Havoc is actually just a plugin of the engine? Didn't know this, but it indeed sounds very weird for an engine like this. How can at least a basic physics engine not be part of the design (this to me includes "stuff not falling through the ground", as well as slightly more complex physics than boxes - doesn't have to be full blown high-poly mesh physics (that could be a plugin), but boxes alone won't do the trick, not even for basic things. Boxes are good as a first pass to filter which objects are candidates. At the very least, to even just do the basics, overlapping boxes, spheres and cyliders are required. And that's for simple things only).

 

Then again, i'm talking about the developers who also had the great idea of using a potatoe.... err, i mean an interpreter, that cannot even jump over irrelevant blocks in control structures... to run all of the game's scripts - so maybe i shouldn't be surprised anymore.

Link to comment

Beth use several nominally independent SDKs these days (in a pretty lazy fashion I might add).

See http://niftools.sourceforge.net/wiki/Nif_Format/Nif_Resources for a VERY partial list of games based on the NetImmerse/Gamebryo 3D engine. There are a lot more, if you care to peruse the Niftools 'Other Games' section. Bridge Commander is the oldest I'm aware of with Version 3.0 (that far back!). Me, I first came across it with Freedom Force and version 4.0.0.2 (same as Morrowind). I might add that Irrational Games were far more supportive a fans than Beth have ever been. They released decent 3DSMax exporters and tons of documentation.

 

Beth now (but didn't originally) use Speedtree and Havoc to name but two third party SDKs. These can (so I'm told) use any engine, including Gambryo.

 

Don't blame any of the engines for Beths strange decisions. (Males and Females using the same Skeleton in Oblivion anyone?).

Link to comment

using the same skeleton is not the problem actually that made it easier to have 2 animation created from blend file if both skeleton where different you need 2 separate blend file in order to create an animation correctly.

 

As for the engine it really is a problem from day one. they never actually optimized it that well and that is why even now when you use fallout you will actually see they never really did anything on the optimize part there are even oblivion leftovers in geck. :D

Link to comment

If I may offer a suggestion:

 

Some undressing animations. For example LoversStalker M has rapists order the PC to strip in stages (shoes, top and bottom), but this is done with simple unequipping. I mentioned it to mem4ob4 and he said it would be possible to add animations to each undressing order. I think said animations could be usable for more mods too.

 

I had origonally thought of the bathing animations, but I cannot find the mod anymore, besides these aren't quite "sexual".

Link to comment

Beth use several nominally independent SDKs these days (in a pretty lazy fashion I might add).

See http://niftools.sourceforge.net/wiki/Nif_Format/Nif_Resources for a VERY partial list of games based on the NetImmerse/Gamebryo 3D engine. There are a lot more, if you care to peruse the Niftools 'Other Games' section. Bridge Commander is the oldest I'm aware of with Version 3.0 (that far back!). Me, I first came across it with Freedom Force and version 4.0.0.2 (same as Morrowind). I might add that Irrational Games were far more supportive a fans than Beth have ever been. They released decent 3DSMax exporters and tons of documentation.

 

Beth now (but didn't originally) use Speedtree and Havoc to name but two third party SDKs. These can (so I'm told) use any engine, including Gambryo.

 

Don't blame any of the engines for Beths strange decisions. (Males and Females using the same Skeleton in Oblivion anyone?).

 

@ Symon - I've been curious for quite some time on points you raise here. Is it at all possible to enhance aspects of Oblivion where Beth feel short? Would that require a complete rewrite of the EXE?

 

Link to comment

Well, yes. That's what OBSE does in part.

For a more radical approach, just look at the Morrowind code patch for an example of how changes to the actual executable can be made to fix bugs and enhance the engine.

Using a disassembler (I presume) a phenomenal number of Beth bugs have been removed. Graphics and animation limitations imposed by silly Beth decisions and/or mistakes have been removed (Gloss maps implemented, better animation handling, etc), save games are more robust. The list is quite large.

Link to comment

I feel one very phenomenal improvement, but it would I'm certain require a decompile/recompile of the exe, is to rebuild it to make use of multicore processors. Two would be a vast improvement, four would be awesome. Then channel, audio to one, graphics to a second,etc. I wouldn't even try going from 32 to 64 bit as that would I assume be essentially a total rewrite of near all code.

 

Nice to dream, but doubt it'll ever happen.

Link to comment

The problem with making something multicore AFTER THE FACT, is that most of the code might rely in sequential execution. If a subsystem of the engine is nicely abstracted away from the rest, and ideally already has a command queue mechanism... then it's halfway easy to multithread it.... because all the groundwork has already been done. If instead a subsystem is just as interwoven with other "modules", as MS software for windows, barely has any abstraction and no "queue" whatsoever, then you basically have to rewrite that entire part of the engine, and then rewrite how all the other parts access it.

 

I suppose obvious candidates, which might with some luck (okay, a lot of luck, given that this is beth) fit the above requirements, AND provide a nice performance boost, would be:

 

1. Havoc. The whole thing afaik is already using "virtual threads" (probably coroutines) anyways, so the api and queueing probably is already there.

 

2. That dumb as brick script interpreter of theirs - almost certainly, there is already some kind of "scheduler" in the engine. Scripts might not easily be runnable in parallel, but if at least ONE script at a time can be executed parallel to the rest of the engine, then this still would be a plus.

 

3. With a lot of luck (really a LOT), the render subsystem might be multithreadable - it should be obvious why this would bring a major performance boost. The problem is, that i have a really bad feeling, that the render api is tightly integrated with other subsystems, and almost certainly they all operate on the same shared worlddata... which makes any multithreading pointless, since it would be dragged down in mutexes.

 

P.S.: A pseudo 64bit binary might actually be possible - with some limitations. If one already has the disassembled code, all nicely cleaned up... then one could compile it to run in 32bit more but "large addressspace aware". Replacing the memory allocator shouldn't be too hard - heck OSR already is doing it. Most of the engine would remain limited to 2GB, but for a few small but ressourcehungry subsystems, one could hack them to make use of the additional memory. The downside is, that this will not work out of the box for the player. Windows has a switch in one of its configfiles, to enable this extended addressspace mode. By default, it is disable. Why? No idea, i guess they needed a reason to sell 64bit OSes. Who back then would have switched to a 64bit OS, when the 32bit RAM limitations are gone (in the midterm) ? It's a bit like what intel and then AMD did with their CPUs. Want to know why stuff is so much faster in 64bit mode? It's not 64bit. Instead, with 64bit CPUs they introduced additional features and cpu registers, that got nothing to do with 64bit itself. Then they artificially disabled those features in 32bit mode, so that to people it looks as if 64bit makes stuff so much faster.

Link to comment
  • 2 weeks later...

This reminds me of Open Morrowind, which is a engine reimplementation of Morrwind, with all engine features of any modern engines (Multicore- Multithreading support, 4GB, 64Bit support,OpenGL,... ) and full mod support.

 

 

Let's hope they will make that for Oblivion too.

Link to comment
  • 2 weeks later...

I always wonder why females can't rape beasties and have to submit to them instead...same with males not being able to rape female beasts like the daedra spider queen.

 

That would require an expansion of the current Lovers Creatures MOD and animation sets. The initial focus was on collecting all-under-one-roof updating & expanding PC/NPC animations first. Creating animations is so very very time consuming. Now that there are more Oblivion animators, you may see them one day.

 

Link to comment

This issue is not animations, the issue is coding.  Beasts were set up on a one way system coding wise with lovers.  It takes hundreds of hours of coding to reverse that.  So far, no one has stepped up to the plate to take that on.

Link to comment

This issue is not animations, the issue is coding.  Beasts were set up on a one way system coding wise with lovers.  It takes hundreds of hours of coding to reverse that.  So far, no one has stepped up to the plate to take that on.

 

In progress, albeit on hold presently while crazy life stuff gets sorted out.

Link to comment
  • 4 weeks later...

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use