Page 7 of 10

Re: Post 1.0 Plans

Posted: 28 Jul 2018, 12:51
by AnyOldName3
  1. Other file formats will be added over time. The main problem with doing this right now is that our animation system is bespoke (as OSG's provided one wasn't compatible with Morrowind's animations) and we'd have to write a loader ourselves for the animation system for any new formats.
  2. OpenXR hasn't even been released yet, so we can't plan for it yet. Until it is released, there's no way to add VR support to OpenMW as no existing VR libraries are compatible with our licence.
  3. The CS is going to support Python-based plugins. This is already planned.
  4. The term PBR has sort of got messy. There's the shading part, which means using maths which approximates light reflections, such as Cook-Torrance, instead of maths which was fast on the computers available in 1975 and vaguely looked like light, such as Phong. Support for this will be added at some point, but people will have to remake all of Morrowind's assets as textures and materials designed for the classical system don't have all the information needed by a PBR system. The other component is image-based lighting, which strictly speaking, is completely orthogonal to PBR (as you can have one without the other) but lots of people seem to think it's the main feature of PBR. This involves having precomputed renders of the world in all directions taken from lots of positions which can be used to look up how much light comes from which direction. This means that these renders have to be made in the editor and become outdated whenever any objects are added, removed, or repositioned. It's not really suitable for a Morrowind-like game (hence why Fallout 4 doesn't do it and therefore why lots of people claim Fallout 4 was lying about being PBR) as mods can add new content and objects can be changed during the game. It's also a massive nuisance to add it into an engine which wasn't designed for it in the first place. If this ever is added, it's almost certainly going to be restricted to new OpenMW-based games and not Morrowind.
  5. Tools are always nice

Re: Post 1.0 Plans

Posted: 28 Jul 2018, 18:38
by Chris
AnyOldName3 wrote:
28 Jul 2018, 12:51
The other component is image-based lighting, which strictly speaking, is completely orthogonal to PBR (as you can have one without the other) but lots of people seem to think it's the main feature of PBR. This involves having precomputed renders of the world in all directions taken from lots of positions which can be used to look up how much light comes from which direction. This means that these renders have to be made in the editor and become outdated whenever any objects are added, removed, or repositioned. It's not really suitable for a Morrowind-like game (hence why Fallout 4 doesn't do it and therefore why lots of people claim Fallout 4 was lying about being PBR) as mods can add new content and objects can be changed during the game. It's also a massive nuisance to add it into an engine which wasn't designed for it in the first place. If this ever is added, it's almost certainly going to be restricted to new OpenMW-based games and not Morrowind.
Could always use a predefined light list, along with screen-space reflections to add a bit of detail, couldn't you? Or automatically generate and cache light probe data when loading a cell (perhaps have a mod place Light Probe objects at desired locations, but leave the engine to generate them asynchronously at run-time).

Re: Post 1.0 Plans

Posted: 29 Jul 2018, 00:22
by AnyOldName3
It starts to look weird if the light probes are further apart than about once every metre. This needs to be in all directions the player could move, too, so as there are magic effects which practically make the player fly off into the sky, that's far, far too many renders to do at runtime on cell load. I guess that the density doesn't need to be as high at higher altitudes as the angle between different objects on the ground doesn't change much, but it's still a huge amount of computation if it's to be noticeably better looking than just having one environment cubemap per cell.

Also, as we have a light source which changes position over time, every light probe needs many different versions over the day-night cycle. The only PBR games with a day-night cycle that I've played are Fallout 4, which doesn't do IBL, and MGS5, which, for every location, has a pre-baked light and reflection map for every hour under every weather condition, which is not something that can remotely be achieved at runtime.

Re: Post 1.0 Plans

Posted: 29 Jul 2018, 01:09
by Chris
Isn't it possible to mix real-time lights (magic projectiles, torches, etc) and light probes for other lights that don't change often (and thus would be okay to asynchronously rebuild the probe data)?

Re: Post 1.0 Plans

Posted: 29 Jul 2018, 11:52
by AnyOldName3
It is, but then a fort gets destroyed or a mod adds a new building or tree to a cell, and that whole cell's light data is now invalid and needs regenerating. For the statics-get-changed-by-a-script case, it would be just about feasible for people to mark things in the editor which get modified by scripts and say which possible combinations of enabled and disabled exist, so while complicated, it's not impossible, but if mods are allowed to change things, you can't even let the mods include the updated lightmaps as another mod could change the same area and then you'd need compatibility patches for every combination of mods or users to sit through potentially hours of baking their own lightmaps for their own combination of mods.

Re: Post 1.0 Plans

Posted: 29 Jul 2018, 20:23
by Chris
AnyOldName3 wrote:
29 Jul 2018, 11:52
It is, but then a fort gets destroyed or a mod adds a new building or tree to a cell, and that whole cell's light data is now invalid and needs regenerating. For the statics-get-changed-by-a-script case, it would be just about feasible for people to mark things in the editor which get modified by scripts and say which possible combinations of enabled and disabled exist, so while complicated, it's not impossible, but if mods are allowed to change things, you can't even let the mods include the updated lightmaps as another mod could change the same area and then you'd need compatibility patches for every combination of mods or users to sit through potentially hours of baking their own lightmaps for their own combination of mods.
My idea was a mod could set down Light Probe objects at relevant points that lightmaps should be generated at, but the actual images aren't generated by the CS. Instead, when the game loads a cell it asynchronously renders the cube maps or whatever at the positions Light Probe objects are placed, baking in "static" lighting for IBL. If a script disables/enables/moves a static light, the engine will asynchronously re-render the cube maps affected by the change. Obviously this means modders should be careful about changing static light sources often (it's kind of the point of static lights that they're, well, static, not changed often), and instead consider using dynamic light sources if they're going to be changed a lot. We could allow for some tricks with static lights too, where they can slightly change position/color/intensity over time, but bake it in to a light image using an average that doesn't need updating. A mod would of course have to mark light sources as being fully static, fully dynamic, or pseudo-static for the engine to handle them correctly.

One other thing about Light Probe objects is they should probably be treated as a singular group per cell, rather than individual objects. So if two mods place Light Probe objects in the same cell, none of the lower-priority mods' light probe objects are used in the cell while all of the higher-priority mods' light probe objects are. That way you can have a mod that places light probes all around vanilla content, while having a mod that re-landscapes specific cells and places down light probes at new points in those cells, without the probes doubling up in those cells.

Screen-space reflections, and the mix of real-time/dynamic lights and IBL of static light sources, seems to me it'd cover the lighting pretty well. If a screen-space reflection is available for a particular pixel, use it, otherwise probe the lightmaps and mix in dynamic light sources.

Re: Post 1.0 Plans

Posted: 30 Jul 2018, 23:20
by AnyOldName3
As I just said, we can't render the lightmaps from the light probes when loading as it's likely to take several minutes (or potentially an hour) per cell, and then every time a light is changed or any static object is enabled or disabled, this has to happen again. The lightmaps need to have every largeish object in them and really should be rendered with full global illumination, which takes ages.

tl;dr: your suggestion solves about the easiest 3% of the problems, but none of the hard ones, which all revolve around baking lightmaps taking a lot longer than a regular frame and there needing to be a lot of them.

Re: Post 1.0 Plans

Posted: 08 Aug 2018, 12:11
by Br0ken
About non-NIF animation support:
Just found this library http://guillaumeblanc.github.io/ozz-animation/, looks quite good.
Fbx, Collada, obj, 3ds, dxf support (gltf2 in roadmap), recently updated, MIT license.

Or osganimation will be better for OpenMW?

Re: Post 1.0 Plans

Posted: 08 Aug 2018, 13:10
by MiroslavXO
Does that mean that I can make custom rigs, animate them and import into a game?

Re: Post 1.0 Plans

Posted: 08 Aug 2018, 15:26
by psi29a
osganimation does a lot for us already, otherwise we would have to shoe-horn the other animation sub-system into OSG.

osganimation in combination with the dae plugin gives us collada animation, especially if we use https://github.com/sbarthelemy/daenim as a guide.

yes, that means custom rigging... not longer bound by the constraints of morrowind style NIF.