OpenMW support for other games: Oblivion, Skyrim, Fallout and more

[Capostrophic]

wtf

how

[CMAugust]

Wow wow wow!

[silentthief]

That is awesome

ST

[Atahualpa]

Very nice! Keep on your good work, cc9cii.

[cc9cii]

An update - https://youtu.be/mM1lE8frdYc

Now the visible meshes move and a light source was added but there are many issues still. The lamp doesn't collide with the ceiling and I'm not sure how to add a flame to the lamp. The impulse from the collision with the player is way too large. Just a small bump sends the lamp flying off...

[raevol]

Sounds about right for Oblivion... hah. Great work!!

[psi29a]

I've been having an on-off conversation with cc9cci about the future of this fork and figured it a good idea to post here. It should probably pump most of you up, but I hope it is to also offer encouragement to cc9cci for all his work on this project in between sleep and his day job.

I asked if there were plans to merge the Oblivion work back into OpenMW itself or would it be a fork.

TL;DR
I've not really thought much about what will happen to be honest.

Long answer:
The code as it stands is "experimental" at best and not suitable for merging (a lot of hard coded stuff and shortcuts). A lot of sins were committed in the name of "getting it working".

And given the lack of facegen and speedtree I'm not sure if this will go anywhere ever - it would be a strange game where everyone looks the same. However the speedtree issue can probably be worked around using lookup of other models.

I suspect significant parts of OpenMW will need to be re-written (physics, for example) and therefore merging the code back to the master branch won't be easy.

I reminded cc9cci that the physics is currently has a lot of eyes going over it at the moment, that having it re-factored with Oblivion physics in mind isn't out of the question, though obviously a post 1.0 thing. As for facegen and speedtree, they are 3rd party libs that we don't have access to. We can put in placeholders which should be 'good enough'.

I then asked what it would take to get us into the Imperial City and terrain rendering in OpenMW (master):

With regards to how much change to get to Imperial City - well I can do that now from the console but otherwise scripts will need to work. I've not done any script integration yet (although that's next after ragdoll since scripts are required for some doors and containers).

More detail:

So far I've ignored the BSA (I suspect it isn't too difficult but just not so interesting so didn't get around doing that, since there are BSA extractors around there's probably enough info to get that done reasonably quickly). I've just copied the required files into the Data directory.

The other key parts are:

- Loading ESM/ESP files in TES4 formats (although TES5 is also mostly supported). Currently not all records are supported or loaded, mainly those that have game play aspects such as CLASS, RACE, etc. Even those that are loaded, not all subrecords are handled since nobody seems to know what they are meant to do. This code is in my usually messy style, but good enough for merging since I've made it as an external library anyway. Any hacks required to make it work alongside TES3 are already available for OpenCS and OpenMW.

- Loading new NIF formats. Most NIF records types are loaded but not all are handled (i.e. new type of particle effects, animations, etc). This is based on the current OpenMW framework and I am not 100% happy with it (or some of the existing implementations). The new files in "components/nif" will need to be cleaned up a bit before it can be merged - and probably will generate some discussions.

- Handling of the NIF models. There are two types for the newer NIF versions, visible mesh/triangle/skin and physics shapes (well, there might be more that I'm not aware of). These are not done well at all, I just hacked and hard-coded to get stuff working. I'm currently looking at the physics part and it it taking a very long time because I'm having to rewrite constantly as I learn more stuff that invalidates my earlier assumptions... Still, all that could be cleaned up without too much trouble for merging (since the functionality of the newer NIF's don't overlap the old in most cases) The trouble will be the reliance on Ogre.

- The glue between above and the current OpenCS/OpenMW. Well, this is going to be the most controversial. I can't see too many people approving the way I've modified the CellStore, for example.

Finally, I've used MSVC 14.0 and C++11 in some places (a lot in OpenCS). I've not tried to compile in Linux yet.

So, in summary, I don't think this is in shape to be merged at this point (if it should be merged at all given all the invasive changes). Also, I would like to get the animations to work properly (and OpenMW 1.0 released - I wouldn't like to be a distraction to the main effort) before anything is released on github. A good gating test might be to run Morroblivion and see how it handles - better graphics/physics/animation/AI but still with Morrowind gameplay mechanics.

So it seems that this isn't a permanent fork, but a long running feature branch. Keep in mind, Oblivion game-play isn't even talked about at the moment. Just rendering Oblivion in the Morrowind context. It does get us one step closer.

Congratulations cc9cci!

[DestinedToDie]

I know things like speedtree and physics are part of Oblivion. But considering that physics is in the post 1.0 wishlist, wouldn't it be more realistic to leave it be for now? I don't remember it being essential in a way that it would stop you from playing the game were it for some reason disabled.

[Biboran]

Actually I thing Oblivion no need physics, it maded there just because physics hype

[jirka642]

I think, that some traps required physics to work...
But that might be all.