Asset Replacement Reboot

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
User avatar
Ravenwing
Posts: 334
Joined: 02 Jan 2016, 02:51

Re: Asset Replacement Reboot

Post by Ravenwing » 28 Sep 2019, 00:24

Sorry, meant to post on this before now, but want to respond to these before I go full wall-of-text ;)
Berandas wrote:
27 Sep 2019, 18:56
Just FYI I am still keeping the whole MOAR thing alive on my Gdrive (data-wise) and there are still people doing little contributions from time to time. I also shared it with the Atlas project some time ago.
Though I should probably do a little cleanup and update the files and guidelines for the newest Blender version.
Wonderful! Do you only have copies of the final NIFs or do you have the working .blend files as well?

I'm guessing this is your own personal drive? People are still contributing so do you have any kind of infrastructure set up, even if it's just a Sheets document with a list? :D
Mistahtokyo wrote:
26 Sep 2019, 16:02
A total lack of structure would not be good, nor a free-for-all grab since, while the total mesh/texture count is high, there are generally popular/common meshes and textures that are more likely to see work than others. In that case, it's good to establish some idea of what's being worked on. At the very least have a forum style setup for people to claim assets, then a common upload spot to dump the progress in.
Agreed, I was planning to have some sort of poor man's tracker/list of assets to kind of keep track of what's going on and who's trying to work on what. If this gains any momentum at all, I think the main OpenMW team will be happy to set up a subforum if it even needs that much.
Mistahtokyo wrote:
26 Sep 2019, 16:02
Certain rules need to be established as well, such as how long a claim can be held without progress before being opened up for others. Another good thing to consider is ordering the meshes into a list of most used/visible in-game to least so that the project can start out taking on the most important/noticeable pieces first, then gradually work down to things like rings and amulets, etc.
I have more thoughts on this that I'll share in my next post, but I don't think that's even worth worrying about. Almost everything is going to stick out like an especially sore thumb simply because of additional polys and normal mapping until it's all complete
Mistahtokyo wrote:
26 Sep 2019, 16:02
Edit: Also before even starting out, has anyone asked recently whether or not projects like Skywind have any interest in sharing/releasing assets for use in Morrowind? Ideally the project should make use of existing modern asset replacements to avoid duplicate work.
As lysol said, it has been brought up a few times, and maybe I'm not fully aware of Skywind's design philosophy, but I think the even bigger problem than getting various permissions is the fact the meshes won't physically match existing assets. Tiling sets are a particular problem, but even then, if things like barrels or tables are slightly different sizes we'll have too much clipping/floating etc.

Edit: Forgot to respond to AnyOldName3's bit. Most of it I will discuss in the next post, but figured this might shed some light on a couple key points that I'd rather not enumerate there.
AnyOldName3 wrote:
23 Sep 2019, 01:41
One thing I'd like if we were doing a MOAR reboot would be to make sure that all new assets have a PBR material set up, otherwise we're going to have to start again in a few years. At this stage, we're not settled on what parameters we're going to eventually support, but for the most part, any sensible set of textures and values can be converted into any other sensible set.
Agreed, and this is one of the main reasons I think many of the old project's assumptions need to be revisited. It's also a much more motivating reason to refurbish the game assets. I know that converters exist between the two workflows, and that they're essentially describing the same things in different ways, but it would also be nice to not have to revisit if possible. Luckily, regardless of which we choose, or indeed if people want to do PBR at all (you should), the first steps will be the same and make a HUGE difference to visuals.
AnyOldName3 wrote:
23 Sep 2019, 01:41
The hard part with this, though, is going to be coming up with a way of baking a PBR material into something that looks okay with Morrowind's gamma-incorrect Lambert+Phong/Gouraud setup so that the new assets can be used in the meantime. While it's theoretically possible (and should be automatable), it's much harder to find a guide explaining how than the other way around (which requires a human to do all the work). Worst-case scenario, I guess someone could write some code that does a bunch of maths to see what gets the most similar results.
I'm not 100% convinced this will even be entirely necessary. I think it's still best to aim for releasing legacy textures simply for ease of user-end setup and so non-OpenMW users can take advantage, BUT I don't think there's any likelihood of MOAR being finished within even 5 years, so by then even the poorest of us should have a card that can take advantage.

It is damn difficult to find info on this. I think here we should just not be too concerned with making it look absolutely equivalent, but relatively close. As long as the diffuse is the right brightness and things don't look to shiny or plastic-y we're good to go. If we did a good job, it would be interesting if someone could write a neural network that learned from our two sets to help artists convert their standard sets into PBR better than some of the other solutions available, but I digress.
Last edited by Ravenwing on 28 Sep 2019, 01:29, edited 1 time in total.

User avatar
Ravenwing
Posts: 334
Joined: 02 Jan 2016, 02:51

Re: Asset Replacement Reboot

Post by Ravenwing » 28 Sep 2019, 06:38

So if we've decided to use a Google Drive to store and keep track of progress until/unless the project becomes busy enough to require a more rigorous solution, let's move on to more fun things to discuss!

First, let's establish a few givens that we should be in agreement on to avoid continuously rehashing old arguments that make no progress:
Givens
  1. Even if it were practical to remake all assets from the ground up and have them fit perfectly into the places they need to go, they would be too similar Bethesda assets to not be considered derivative work. Therefore, there is no possibility of this being anything beyond a Morrowind mod, and can legally only be used in Morrowind.
  2. The main artistic directive is to recreate the vanilla assets as closely as possible to the original game artwork, just more detailed and more modern. Obviously some artistic license must be allowed to interpret what some of the low res stuff actually is or what material things are made from, but it isn't meant to be a reimagining or "inspired-by" mod.
  3. The primary scope of this mod is to show off OpenMW and its (future) graphical capabilities in a complete and useful way. It need not be limited to this, but OpenMW is the main target.
  4. This is a Cathedralist project. Basically by definition an open collaboration has to be, but anything else would be antithetical to being built alongside OpenMW.
The first point is really to help us limit what we're trying to do and control expectations as well as reduce misuse of the mod. There can't really be any reasonable expectation that what we do will be free of Bethesda IP, so there is no need to jump through hoops to try and make it so (e.g. build every mesh completely from scratch).

I don't really expect there to be much disagreement on the second point. I think most people nowadays who enjoy Morrowind agree that the vanilla aesthetic is one of the main features of the game. Not only is this likely the most popular direction to go in, it also builds in some objective (more or less) artistic control. Any other choice will fragment artists wanting to go in their own directions and make it less likely the project will be completed.

The third point is obvious given where the project is starting from, but I'd like to keep from having arguments about how we need to include provisions for every single tangential Morrowind related project. I absolutely would love to produce great legacy texture versions and support MGE-XE's PBR implementation, but any time the question comes between doing something the best way for OpenMW or making something mediocre so we can do something 3+ different ways, the objective should always be clear.

This touches upon some of the bits that need more discussion:
Goals
  1. PBR. If we're trying to update assets to be part of the modern world, this seems the best way to do it. Plus the main graphics programmer of OpenMW supports it, so like, let's do it.
  2. Modders resource. This project should not aim to be the be-all end-all replacement for assets. Instead I think we should consider it more like the starting baseline for the modding community to do what they do best.
  3. Drop-in asset replacer. Just because we're not arrogant enough to think no one will want to mod on top of it, doesn't mean it shouldn't be able to stand on it's own as a fully functional asset replacer.
  4. Decent performance. I don't think we need to obsess over squeezing out every last ounce of optimization, but we should maintain a reasonable level of performance on modern systems.
  5. Coevolving. I'm less keen on this one, but I thought it worth mentioning. As this project is largely meant to showcase OpenMW's graphical abilities, it seems like a good idea to replace assets using features we support. This is getting into the realm of feature creep, so probably should just leave this to other projects.
The first goal is what changes some of the conversation from before. There was lots of talk of maybe trying to maintain compatibility with existing texture packs, but maybe not because UV maps were trash anyway. An attempt to maintain backwards compatibility would theoretically be nice, but with PBR this is basically impossible, so having this as an objective kind of seals the fate into creating all new textures. A decision to go with PBR does not immediately change any of the short term goals of the project (creating meshes), but it helps with direction and interest. It does however affect many aspects of the overall project, so I'll attempt to bring them up as they become relevant.

The second goal was implicit in the project before, but I think it's important to state officially. Part of this is to manage expectations. It's a baseline that we're expecting people to improve upon. The reason we want to recreate ALL assets, apart from simply looking nicer, is to provide an artistically uniform foundation for new mods to grow on top of. This is especially crucial with PBR as a goal as there can't be any mixing of legacy and PBR and have it look good. We are already (unfairly) criticized for being unfriendly to modding, so this should be something of an olive branch goal. No single modder who wants to make something PBR for OpenMW could hope to make their project fit in with existing assets; this project will allow them to focus on the assets that they're interested in creating.
As a corollary, I would say this includes providing some of our intermediate resources such as the material brushes we use for each tileset. That way if modders want to create new models that match our new vanilla, it's very easy.

The third goal is merely for clarification that we do want this to still be good. It also brings up an important PBR point that I'm sure AnyOldName3 is screaming at his screen about right now ;) While this project should aim to be drop-in, we've discussed at length that PBR texture replacement is not a simple plug-and-play kind of mod. Part of this project, or a close companion project, at minimum must be adjusting lighting settings and sources throughout the game to be appropriate for PBR. I know this kind of contradicts this goal, but it is an essential requirement and really works into goal two so others can take advantage of PBR as well.

Goal four is also to manage expectations, but make it clear we're still dedicated to making this work. A baseline should be functional after all.

This last goal, as I say, is a little wonky. Not really sure where to draw the line. I think to support what we can as easily yet rigorously as possible without going hog-wild and adding all kinds of new features. We HAVE to provide widespread bump-map and normal map use at a bare minimum. I would suggest node switching on flora, but not for glowing windows. I don't know if this is really the way it would be implemented, but if we have procedural grass controlled by maps in the landscape, we should provide those maps with the textures.

A few last thoughts.

I know you had been opposed to hi-res models of everything Berandas, and not sure how your views have changed on this, but I really don't see any way of creating great height-maps without baking them on. We don't need to model every brick, procedural texturing should take care of this nicely enough, but bump-mapping things really makes a huge difference on a ton of stuff. Obviously not everything needs it, but it should still be considered as a basic part of a modern workflow. I don't know when parallax mapping was added to OpenMW, but perhaps that was why it was not originally necessary.

I haven't talked much about the MGE-XE PBR implementation, but I don't see a reason we couldn't use this as an interim way of testing our materials, if we somehow get to the point of being able to start textures. Doing this should also help drum up talent support from other areas of the modding community.

We talk almost exclusively about meshes and textures, but there are plenty of other assets that really need remakes as well.

In terms of areas to focus on, while it would be great to have a whole team working diligently on a nicely prioritized list of to-do items, I'd really just rather get as many people working on this as possible. It's kind of like OpenMW; since it's volunteer work people are just going to work on what they feel like. That being said, I think it might be prudent to try out a single area, Balmora for example, and completely redo all the assets there to make sure our workflow is reasonable and efficient before moving on to everywhere else.

That's all I can think of for now. Hopefully I've brought up some good points and hope you all have some thoughts on the matter. Hope there's not too many typos and grammatical mistakes, but it'll have to wait for morning lol. Looking forward to working with you Berandas and getting this thing back up and running!

User avatar
lysol
Posts: 1425
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: Asset Replacement Reboot

Post by lysol » 28 Sep 2019, 09:32

This has my attention.

---

Is there any nif-exporter working for the latest blender nowadays? Because there wasn't, last I tried. If yes, then maybe, maybe I could have a go at redoing some hlaalu house or whatever, make some kind of atlas (maybe even base it off of project atlas' maps? At least to have something to start with.) UV and smack some PBR-ass textures on top of it. Since this monday, I'm down to 50 % parental leave (my wife works from home and don't work full time anyway, so it made sense for me to grab some of that free money too), and I'm writing this with him sleeping on my chest. Who knows, maybe I could find some time to make models and textures with him sleeping on my chest......

But really I shouldn't talk like this. I'll probably only end up disappointing myself and others.
Normal mapped texture replacers, exclusive for OpenMW:
My Nexus page

User avatar
Berandas
Posts: 96
Joined: 28 Oct 2012, 11:23
Location: Prague, Czech Republic
Contact:

Re: Asset Replacement Reboot

Post by Berandas » 28 Sep 2019, 10:12

Ravenwing wrote:
28 Sep 2019, 00:24
Wonderful! Do you only have copies of the final NIFs or do you have the working .blend files as well?
I'm guessing this is your own personal drive? People are still contributing so do you have any kind of infrastructure set up, even if it's just a Sheets document with a list? :D
I have all the source files for the new models, the folder structure is set up, the pipeline documents and a sheet of assets are ready, if you can PM me your gmail adress, I will share it with you. We never reached the second phase, which was about redoing the vanilla textures, so we only have models.

I agree that having PBR materials would be great, but in my opinion this should be a second pass after the basic models are fixed/optimised/ready. There are several things to keep in mind, the MGE XE PBR prototype works, but it is far from perfect and it is not as actively developped afaik, I believe there are still some imperfections with albedo colors and so on.
I was releasing two PBR replacers this year and it was no easy job to get them look at least average. The usual problem is that you're previewing the stuff in different renderers while working on it (Marmoset Toolbag, Substance, Quixel Suite, Blender Cycles, Blender Eevee, etc.), the look usually differs slightly between them, but at the same time differs significantly between them and MW, in many cases it involved a lot of guesswork and trial and error to get things done.

I am not against sculpting everything, I just know that the production time difference can be very significant (for example going from two days of work per object to two weeks of work) and also I am no pro-sculpter, so that would slow the production even further (and being a perfectionist that I am, I would never sleep calmly, knowing that the work is not perfect).

One of the things that I also started doing was constraining the UV islands within the 0-1 UV space (or at least in one of the axis), so they can be easily atlassed when necessary.

Another major production bottleneck are the Blender export scripts by Greatness7, which are still in development. I think there is currently some progress being done on the animation import/export level, but what I am waiting for the most is the custom vertex normal export, wich is essential for hard-surface models and especially when they're supposed to be using PBR (Currently all my models have it, it just can not be exported.).

User avatar
Mistahtokyo
Posts: 134
Joined: 07 Sep 2013, 18:31

Re: Asset Replacement Reboot

Post by Mistahtokyo » 28 Sep 2019, 15:47

Ravenwing wrote:
28 Sep 2019, 06:38
That being said, I think it might be prudent to try out a single area, Balmora for example, and completely redo all the assets there to make sure our workflow is reasonable and efficient before moving on to everywhere else.
Selecting a region/city and replacing the assets that apply to it first seems like a great way to start. Not only would progress be more readily visible, once the city has been replaced promotional content can be made to showcase the project and further attract interest. It's harder to showcase tons of spread out assets vs a single cohesive city set and Balmora is generally a good example whose replacements would affect quite a few areas.

Edit: Also, while a close to vanilla replacement is a good starting point and should be the goal for finishing the project, I do hope that eventually assets get more comprehensively reworked, then hand replaced to fit. Some architecture pieces, due to the tiled setup used, have a very Lego sort of flatness that you can only alleviate so much without deviating from the exact shapes.

User avatar
AnyOldName3
Posts: 1858
Joined: 26 Nov 2015, 03:25

Re: Asset Replacement Reboot

Post by AnyOldName3 » 28 Sep 2019, 17:07

I agree that having PBR materials would be great, but in my opinion this should be a second pass after the basic models are fixed/optimised/ready. There are several things to keep in mind, the MGE XE PBR prototype works, but it is far from perfect and it is not as actively developped afaik, I believe there are still some imperfections with albedo colors and so on.
I was releasing two PBR replacers this year and it was no easy job to get them look at least average. The usual problem is that you're previewing the stuff in different renderers while working on it (Marmoset Toolbag, Substance, Quixel Suite, Blender Cycles, Blender Eevee, etc.), the look usually differs slightly between them, but at the same time differs significantly between them and MW, in many cases it involved a lot of guesswork and trial and error to get things done.
If you've got correct PBR materials, they should look right in any correct PBR renderer under any lighting conditions. However, if you've just been aiming to get the right results in one renderer or one lighting setup, it's possible to make something that looks right there, but actually isn't a correct description of the material, so looks wrong in other situations. There might need to be some basic conversion between renderers (e.g. you'd need to convert roughness into glossiness by negating a texture if you'd made a roughness map and tried to load it into something that only did glossiness, or something might use different curves to convert from texture values to floats in the shader) but I'm pretty sure most tools that do anything weird can do that automatically - after all, it would be hard to sell a PBR material designer if it couldn't export to or import from what Unreal or Unity use.

I also don't think we should do PBR as a separate pass after the fact. The main thing holding things back is how everything is so interdependent, so we can't change the lighting model or add gamma correction or make an overhaul mod that tweaks all the lights in the game unless it's all done at the same time, but at least if we have PBR materials, we can test them in other tools to see if they're right, and then we've got justification to start on the engine-side and ESM-side stuff. If you're coming in with no texturing experience it should be easier to learn a PBR workflow than a legacy workflow, and if you've got experience, but have enough practice to not accidentally do dumb legacy-style things while making PBR materials, making PBR materials should be easier than legacy ones. After all, you can just look up the values for lots of common materials and use them verbatim, but at best, legacy stuff is finding or drawing an image and then messing with it until it looks kind of right.
AnyOldName3, Master of Shadows

User avatar
AnyOldName3
Posts: 1858
Joined: 26 Nov 2015, 03:25

Re: Asset Replacement Reboot

Post by AnyOldName3 » 28 Sep 2019, 17:11

Also, regarding how closely we should replicate vanilla assets, it would be nice if we could keep things as similar as possible without them counting as derivative work, otherwise we might as well just subsurf the vanilla meshes, recalculate their normals and UVs, and give them better textures. We should reserve judgement of whether the similar-but-not-derivative line is something worth toeing until someone who knows copyright law has weighed in.
AnyOldName3, Master of Shadows

User avatar
lysol
Posts: 1425
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: Asset Replacement Reboot

Post by lysol » 28 Sep 2019, 19:11

As far as I know, it will count as derivative work as soon as you try to imitate the design of the original. So it's kind of impossible to not touch that derivative definition unless you really take artistic liberties.
Normal mapped texture replacers, exclusive for OpenMW:
My Nexus page

User avatar
AnyOldName3
Posts: 1858
Joined: 26 Nov 2015, 03:25

Re: Asset Replacement Reboot

Post by AnyOldName3 » 28 Sep 2019, 20:07

If the law were that strict, Bethesda would be paying royalties to Gary Gygax for being too similar to D&D. Everything's inspired by other works in some way.
AnyOldName3, Master of Shadows

User avatar
Ravenwing
Posts: 334
Joined: 02 Jan 2016, 02:51

Re: Asset Replacement Reboot

Post by Ravenwing » 28 Sep 2019, 22:36

Regarding legal distinctions: Obviously this is directly relevant to this project, but I think this has a high likelihood of completely taking over the thread while also not ending up being productive. Perhaps it's a good idea to move further legal discussion to a separate thread? I'm not telling you guys off, I just think this is going to attract a lot of other responses with everyone just sharing opinions with little basis in actual legal knowledge or precedent. I'm playing Gloomhaven with one of my lawyer friends tomorrow, so I'll see if I can pick his brain, but likely we need actual legal advise if we want a real answer.
lysol wrote:
28 Sep 2019, 09:32
Is there any nif-exporter working for the latest blender nowadays?
Berandas wrote:
28 Sep 2019, 10:12
Another major production bottleneck are the Blender export scripts by Greatness7, which are still in development. I think there is currently some progress being done on the animation import/export level, but what I am waiting for the most is the custom vertex normal export, wich is essential for hard-surface models and especially when they're supposed to be using PBR (Currently all my models have it, it just can not be exported.).
So glad you guys brought this up, because if there's one thing that drives me crazy, it's having to use 3 different pieces of software in a 7 step process for something that should be done in one and one. The lower the barrier of entry for this, the more likely we'll get a larger population of volunteers. If we're focusing on OpenMW, we should be able to use other formats besides NIF correct? I tried exporting something as DAE but it didn't work, although my guess is I did something wrong. This doesn't solve animations or the initial import of the mesh however.
AnyOldName3 wrote:
28 Sep 2019, 17:07
If you've got correct PBR materials, they should look right in any correct PBR renderer under any lighting conditions...

I also don't think we should do PBR as a separate pass after the fact. The main thing holding things back is how everything is so interdependent, so we can't change the lighting model or add gamma correction or make an overhaul mod that tweaks all the lights in the game unless it's all done at the same time, but at least if we have PBR materials, we can test them in other tools to see if they're right, and then we've got justification to start on the engine-side and ESM-side stuff. If you're coming in with no texturing experience it should be easier to learn a PBR workflow than a legacy workflow, and if you've got experience, but have enough practice to not accidentally do dumb legacy-style things while making PBR materials, making PBR materials should be easier than legacy ones. After all, you can just look up the values for lots of common materials and use them verbatim, but at best, legacy stuff is finding or drawing an image and then messing with it until it looks kind of right.
I suspect the trouble Berandas has been having is because the PBR shader in MGE-XE can only do so much as just a shader, so not a correct PBR implementation in this case. It would be great to get Hrnchamd's input on the difficulties he's run into when implementing our own. I know we've discussed this a bit before, but I think most of your points as to the actual creation of the assets would be helped by using the metallic-roughness workflow. As the modding community on average is amateur artists, the two maps are immediately intuitive and don't depend on looking up a bunch of values for every damn thing we're trying to texture. We would still need an optional map for things that fall outside of this (F0), but anyone advanced enough to know they needed it should have no trouble looking up values. This doesn't really need to be decided yet as we're not even to the point of creating textures.
Mistahtokyo wrote:
28 Sep 2019, 15:47
Selecting a region/city and replacing the assets that apply to it first seems like a great way to start. Not only would progress be more readily visible, once the city has been replaced promotional content can be made to showcase the project and further attract interest. It's harder to showcase tons of spread out assets vs a single cohesive city set and Balmora is generally a good example whose replacements would affect quite a few areas.
Yes! This was exactly what I was hoping to be able to get from it. People are much more likely to want to participate if it looks like we know what we're doing and making progress.
Mistahtokyo wrote:
28 Sep 2019, 15:47
Edit: Also, while a close to vanilla replacement is a good starting point and should be the goal for finishing the project, I do hope that eventually assets get more comprehensively reworked, then hand replaced to fit. Some architecture pieces, due to the tiled setup used, have a very Lego sort of flatness that you can only alleviate so much without deviating from the exact shapes.
I don't entirely disagree, but I think the lego-ness comes from the lack of height information in vanilla textures. Anything beyond that I think we'd have to leave for other mods to build on top of. Depending on the situation we might try and bring stuff like this in after we've already finished the base project.
Berandas wrote:
28 Sep 2019, 10:12
I am not against sculpting everything, I just know that the production time difference can be very significant (for example going from two days of work per object to two weeks of work) and also I am no pro-sculpter, so that would slow the production even further (and being a perfectionist that I am, I would never sleep calmly, knowing that the work is not perfect).
This makes a lot of sense to me, and in many cases I think sculpting isn't even necessary. Maybe I'm prescribing more importance to this than it deserves, but one of the worst parts of Morrowind assets is the number of sharp corners. Even if we did nothing beyond baking in radiused edges where appropriate we'd be able to maintain a lower polycount and let parallaxing do it's thing. My impression is that something between simply subdividing meshes and actual detail sculpting would be the sweet spot. Some things, mostly organic shapes like the Telvanni set and trees etc will need to be sculpted to some degree anyway. Anything ultra-fancy can be revisited at the end of the project or left to other asset packs.

Post Reply