Asset Update to Ogre3D Discussion Thread

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
Post Reply
HeadClot
Posts: 49
Joined: 22 Aug 2013, 21:54

Re: Updating original assets to Ogre3D

Post by HeadClot »

I think before work on the asset replacement should start we need to make OpenMW more artist friendly. Otherwise (Artists) are going to have a very hard time being independent from the programming team by not bugging them every 5 minutes for something that needs to be done. So It would be best to get this stuff out of the way.

Here is what I would be suggesting getting out of the way.

Model / Animation Editor with Animation playback -

Why am I suggesting this -
This would allow us to preview models and get an Idea on Scale as well as preview animations within OpenCS.
As well as find problems with out animations / Models that the creator of said model did not see initially.

.FBX file format support -

Why am I suggesting this -
This file format is supported by pretty much every 3D modeling application under the sun including Blender as of 2.72.
This would also give me the ability to commission a plugin for OpenMW that would allow us to preview our levels in real time based off of existing code.

Example Usage with out plugin
After we are done making our models we would export as a .FBX
We would then import into OpenCS or whatever application we are using.

Example Usage with plugin
http://vimeo.com/101552170

Animation Blend Trees - See here

Why am I suggesting this -
Easier animation blending for the Art Team.

Example usage -
If a character is walking we can blend 2 or more animations together such as walking, Head movement, etc
http://vimeo.com/2007054


Anyway Just my 2 cents,

- HeadClot
MacKom
Posts: 43
Joined: 26 Mar 2013, 13:00

Re: Updating original assets to Ogre3D

Post by MacKom »

Tarius wrote:snip
All I`m saying is - we can do things quickly. Or good. I`m just saying this from my professional POV (I`ve been doing textures for games for years now).

Anyways, all of this is still a long time comming, so there`s no reason to bother with it just now.
RabidSquirrel
Posts: 37
Joined: 18 Dec 2012, 07:52

Re: Updating original assets to Ogre3D

Post by RabidSquirrel »

Sorry, I don't have the attention span to read the whole thread. Are you planning to make a complete overhaul similar to MGSO?

Feel free to use my mods if you want. I may contribute more in the future.

http://www.nexusmods.com/morrowind/mods/43101/?
http://www.nexusmods.com/morrowind/mods/42343/?
User avatar
Berandas
Posts: 96
Joined: 28 Oct 2012, 11:23
Location: Prague, Czech Republic
Contact:

Re: Updating original assets to Ogre3D

Post by Berandas »

HeadClot wrote: Animation Blend Trees - See here
Example usage -
If a character is walking we can blend 2 or more animations together such as walking, Head movement, etc
http://vimeo.com/2007054
This is something I would definately like to see, layered animations, smooth transition between animations, separate animations that could be turned on and off in NPC settings, also it would make animating much more easier. But we have to create new skeletons first, before creating new animation system.
User avatar
domsson
Posts: 13
Joined: 21 Aug 2014, 17:47

Re: Updating original assets to Ogre3D

Post by domsson »

Ah, I've been waiting for this kind of project! Given the vast amount of meshes, textures, animations and other assets, this might be as ambitious as the engine replacement itself. But it could help OpenMW becoming a game rather than a pure engine, so it should be worth it. I'm far from being a professional modeler, and my textures suck, but I do have a bit of experience and usually put out very clean and consistent meshes so I hope I can be of help with a few models every now and then.

However, for this to succeed and to enable contributors to do their job as easy as possible, many questions have to be answered first; most of them have been discussed a bit or a bit more already:
  • What style are we going for? If I understand correctly, if we're too close to the originals (which would be favorable, I guess) it would be derivative work, hence Bethesda could claim copyright infringment or whatever it is called exactly. But if we differ too much, the atmosphere and feel of the game would be changed, plus we might get bleeding and the like. So, what to do? Maybe we should look at how other projects have handled this (OpenTTD?)
  • What are the modeling guidelines? We should agree on a lot of things, like what stuff to have on what layers, where to place notes, naming conventions for objects and materials as well as files and the folder structure, and many, many more.
  • What about LOD? Does the engine auto-generate those, or are modelers supposed to provide custom made LOD models? If so, how many levels are there?
  • What about contributor's rights on the model? Does everything they contribute have to be public domain? Can there be other agreements?
  • How exactly is this orgianized and where can I read up on it? Like some already suggested, there should be a document listing all required assets (whew...) with a screenshot from ingame, info on whether it is not yet done, being worked on or already done and who does/did it as well as some other info. There should be a central place to collect answers to all questions above and a link to said asset list somewhere, maybe a wiki page as someone suggested.
If I might suggest something on the workflow, it would be this: Let's create the models with an unwrap that matches that of the original meshes. This way the new models could simply be used with the vanilla textures. This would have several benefits. First, no need to have super-high-poly models and do custom baking, as that's just not the way the original assets work. And that's good, as it enables heavy re-use of textures and therefore saves a lot of graphics memory. Second, the process of modeling and texturing would be completely independent. Texture artists could re-create the textures and be sure that they will work both on the old and new models. Third, it would enable modelers to have a look at their models with textures applied, without having to wait for the texture artists to do their work. The same goes for users; the models could already be used without the new textures being finished. Of course, this would also go the other way 'round - new textures work on the old models. Hm... well, maybe all of this paragraph goes without saying and I just embarassed myself for pointing out what everyone silently agreed on anyway?

Now, one last thing: Above, I asked about contributor's rights. The reason is that I sometimes create models for Second Life and I do sell them there, too. Once I started re-creating some Balmora buildings. I had to modify the original design, but tried to keep the atmosphere and overall look and feel. Now, my time is limited and I still like to create for Second Life. Of course it would be awesome if I could contribute my works for this project, as well as still use the same models for my products in Second Life at the same time. For example, contribute my "Balmora"-like buildings, yet keep the right to use them elsewhere (in this case: Second Life). But I have no idea if that goes together somehow? I really am a noob about copyright and the like. If it wouldn't work, well, ignore this paragraph (too). ;)

Alright, looking forward to this! :)
User avatar
Berandas
Posts: 96
Joined: 28 Oct 2012, 11:23
Location: Prague, Czech Republic
Contact:

Re: Updating original assets to Ogre3D

Post by Berandas »

Hello Domsson and welcome onboard! :-)

I'll try to answer some of your questions.

The style - as mentioned before, the aim is to keep the same feel as vanilla Morrowind, basically this means to make meshes as identical as possible, just with more details. Because of this condition, all the remade meshes are considered to be a derivative work, so as I understand it, they technically still belongs to Bethesda (as well as all content created for Morrowind through the construction set - I believe this is stated in the license agreement, correct me if I'm wrong).

On the other hand this allows us simply enhance the original meshes (add more geometry and details), I'm not sure if this isn't exactly in conflict with the license agreement, but basically this is happening every day and Bethesda is not making any fuss over it, as long as all the stuff is kept in Morrowind modding.

Another reason why stick with the original shape is simple compatibility, this way it should not cause any placement errors (bleeding, floting or caspering meshes etc.).
This project is technically still a mod for Morrowind, we are not creating new meshes that could be used in OpenMW example suite or anywhere else, all the stuff is strictly bound to the original game (and ofc cannot be sold or imported into other games).
We should also take advantage of replacers that are already done, inspect the meshes if they're suitable for our project and include them, if the authors permit us. This would save us a lot of time and work.
If people are looking for completely new assets made from scratch, they should ask at SkyWind or similar project.
From my point of view it's technically nearly impossible make completely new mesh from scratch, that has basically same shape as vanilla asset (thus making no errors ingame), but is also different enough not to be considered a derivative work.

Talking about OpenTTD, it's using the original TTD libraries for graphics, while also having their own libraries made from scratch, but those graphics are mostly completely different from the TTD ones, thus having no issues with derivative work.

Modeling guidelines - I can imagine there is no need for many guidelines, naming of meshes, materials and whatever else should remain the same for the compatibility reasons. As well as it's necessary to keep the same object origins, scale, UV unwrap coordinates and other things. Same goes for the folder structure.
There are also many errors present on the vanilla meshes, so the secondary aim of this project is to correct them (floating geometry, missing faces, stretched UVs and such).
Hi-poly sculpts are not required, since most of the objects is using multiple materials and have their UV scattered all over, even overlaping each other. Hi-poly sculpts would require completely new UV unwraps for baking textures, which would reduce the number of detail presented on the texture as well as making the meshes incompatible with every single texture replacer made to this day. Also if the user would like to use some new texture on his models, he would have to re-bake the textures in 3D modelling software.


The LoD system is still officially an unanswered question. If there is going to be some sort of "DistandLand" in OpenMW, it's necessary to create a LoD system. But, since we create all objects in LoD0 resolution, there should be no problem to simplify the meshes for other LoDs later, when such a system is present in OpenMW.

Organisation - Deonsion is testing and setting up a databse system this week, that should allow us to simply organise whole claim structure with attached files and everything needed. More information will come after this is done.


Well, I believe I still missed a few things, but it should mostly cover all your questions. If I said anything wrong, please correct me. :-)
Last edited by Berandas on 21 Aug 2014, 20:39, edited 1 time in total.
User avatar
domsson
Posts: 13
Joined: 21 Aug 2014, 17:47

Re: Updating original assets to Ogre3D

Post by domsson »

Berandas wrote:From my point of view it's technically nearly impossible make completely new mesh from scratch, that has basically same shape as vanilla asset (thus making no errors ingame), but is also different enough not to be considered a derivative work.
I agree on this one. That would be an amazingly hard task. Bit sad, as I hoped we could pull off that OpenMW would not require the original game data at some point. Then again, that's probably almost impossible anyway. Also, simply "improving" the originals makes the whole thing a lot easier, so chances of completion increase.

What you said made perfect sense, I'm just still not sure there should not be some kind of modeling guidelines, as well as organizational guidelines. Then again, maybe I'm a bit too extreme in these regards. It is just that from previous modeling collaborations, it simply can be hard to work with other peopel's files if there are no guidelines. For example, regarding what meshes (high poly, low poly, LOD, physics, ...) reside on what layer, how to name the meshes (so they are not all called "Plane.001" through "Plane.079"), what scale and measurement system to use... and so on. The same goes for the folders and files in which the blend files as well as the original files and exported meshes reside. But again, maybe I'm overthinking things and there is no need for people to have to take a look in other collaborator's files anyway.

Also, when I once converted and imported one of the Balmora meshes, I realised that they were split into submeshes based on the materials/textures used (or was it based on flat/smooth shading?). This felt weird to me, but maybe the engine requires this. Then again, maybe Ogre does not. So maybe we can just have one coherent model per object. Questions like that do arise and could be covered in a 'modeling guidelines' chapter on the wiki, too, I guess. :)

Did anyone already start with a wiki page, by the way?

In any case, most important now would be the asset "to do" list and the file server to put everything. Tolchock seemed interested in taking on the asset list task. Also, I was wondering if it is possible if one (or a few) people could take on the work of extracting all the meshes into a blender-readable format (.nif to .dae IIRC) and put them in a work-ready folder structure. But I'm not so sure if that is possible - since the original data should/can not be shared. On the other hand, the file server will require user authentication, I guess, so maybe it is okay then? This way, people could just pick a model and get right to it instead of struggling to install the conversion tools on their system and so on. That would be nice. :)

Looking forward to Deonsion's database and how this all evolves. :)
User avatar
psi29a
Posts: 5361
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Updating original assets to Ogre3D

Post by psi29a »

domsson wrote:Bit sad, as I hoped we could pull off that OpenMW would not require the original game data at some point. Then again, that's probably almost impossible anyway. Also, simply "improving" the originals makes the whole thing a lot easier, so chances of completion increase.
This will happen, as it has to happen. It is one of the main goals of OpenMW, to also be standalone.
User avatar
domsson
Posts: 13
Joined: 21 Aug 2014, 17:47

Re: Updating original assets to Ogre3D

Post by domsson »

psi29a wrote:
domsson wrote:Bit sad, as I hoped we could pull off that OpenMW would not require the original game data at some point. Then again, that's probably almost impossible anyway. Also, simply "improving" the originals makes the whole thing a lot easier, so chances of completion increase.
This will happen, as it has to happen. It is one of the main goals of OpenMW, to also be standalone.
Well, if that is the case, why not just go for it directly? Although it sounds like a monstrous task, really.
But, erm, if it is one of the main goals, why isn't it stated as such amongst the others in the FAQ?
User avatar
psi29a
Posts: 5361
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Updating original assets to Ogre3D

Post by psi29a »

Likely no one has gotten around to it. ;)

The example-suite has been in 'the works' for years now.

We first need to decouple what we expect from Morrowind, so that we don't require that BSA file.

The current work around is to replace every single things in the Morrowind.bsa which is going to be hard work.

I thought about just replacing everything with empty/blank/temp modules/textures/sounds/etc. Then using our openmw.esm with just the bare min necessary to run. That would be a good start.
Post Reply