openmw.org

Hi everybody!

I'm just newbie here, but I'm always has a dream to make modern graphics for Morrowind, especially after I have seen modifications like MGE, so of course I very want to bring some features into the OpenMW.

Right now I'm trying to implement that features
1) Deferred shading system, so we will get essential support of unlimited light sources. Also in perspective it could improve the look of magic system, because we may turn every particle into a small light source)
2) HDR and physical-based shading
3) Light maps at least for Sun, for many sources in perspective (to be honest I do not know how to provide good performance here, but it seems possible because of games like S.T.A.L.K.E.R. was already support unlimited shadow sources something like ten years ago!)
4) Soft particles
5) GPU skinning, tessellation. May be useful at future, but I'm not sure that need right now.

Also I very want to implement distant land rendering, but right now don't know how. It seems I could learn experience of MGE developers, read some papers about rendering, and of course get strong knowleges of the cells rendering at OpenMW.

Depending of the community opinions I could move differently ways.
1) Make a separate branch for my experiments, try to use all techniques that I could, and then wait when another people will return to that features and try to help them in future when the rest of game engine will be finished?
2)Try to gently add features into existing architecture, by adding the experimental options into config file?
3)Maybe we could start the work to hide rendering implementation into interface and then work on different implementations for different purposes? So some platforms does not provide full support of modern OpenGL features, but PC looks very good target for at least OpenGL 3.3+ based renderer.

In all cases I want to remake the existing renderer, not to beginning from zero. But of course I want to contribute into project, not to do something just for myself.

I'm sorry if it looks very ambitiously, I just want to play with graphics and in ideal case provide the fancy image to users
Maybe it's early to change something before project release, but unfortunately I really want to implement something, and I can't wait :/

Of course if somebody doing something same, I will be glad to contribute instead of doing same things individually.

Give 'distant land' a try. We had this in earlier versions of OpenMW with Ogre3D. It was axed when we moved to OSG. Best bet is to get familiar with OpenMW and OSG.

We have about current state of 'distant land' :
viewtopic.php?f=6&t=3870

Basically, we have the ability to view distant land, but it renders everything as if it was up close, so no LOD. Something to try, getting the cells around the current cell and simplifying the terrain mesh. You can probably get away with lower the resolution of the textures as well. Then look into statics, see how you can simplify them as well so that we aren't trying to render them in full detail every frame.

1. If you go for distant land, then the land mesh should be simplified. MGE reads your .esp file and generates a simplified LOD land mesh from it. If you make a blank landscape and load up many cells, you will see that they have a noticeable impact on your fps. Because the land mesh is organic, it can be decimated with an algorythm to produce nice results.

2. Don't we already have textures being simplified via mip-mapping? Perhaps this is already done.

3. Small meshes. Small meshes should be culled and they ought to pop up at only a certain distance once you get close. I believe this is how MGE does things. This could be the same with NPCs and Creatures - they don't need to be active at a great distance. https://wiki.openmw.org/index.php?title ... re_culling We maybe already have this. But only culling objects smaller than 2x2 pixels is perhaps not aggressive enough? Increase the size to 4x4 and see what happens?

4. LOD switching. At a certain distance, a mesh would be switched out with a LOD mesh, if one is present. This would enable a modder to come in after you implement this and make simplified versions of meshes.

---------------------------------------------

I believe at this point the job is done. There is one more thing, but it is problematic and I do not think it is worth tackling. I really do not recommend putting a lot of time and effort into it.

A tool that simplifies all meshes. I believe this is one of the harder things to get right. The reason I say so is that not all models are created equal. Some need a modder to come in and make decisions on how to simplify the mesh and automatizing this process seems very problematic. Meshes can be categorized into 2:

1. Organic meshes. The body shape of a nix hound, the shapes of rocks, etc. These can be decimated with an algorythm to have less polygons while retaining their generic shape. http://i.imgur.com/5NK0RWf.jpg

2.Inorganic meshes. Houses, bridges, etc. You cannot decimate them with an algorythm and expect them to look good, they will lose their shape and look very strange.

-------------------------------------

Of course these are just my thoughts on the matter. I'm not a coder, just a 3D artist, so I mostly have no idea how implementing these things from the code side might be like.

Hello there. You seem to have similar plans to what I had when I joined the project, except now OpenMW is in a state where it is actually feasible to add them

I was working on the distant terrain feature but it got shelved when I became busy with other stuff. Looks like I'll have to finish it soon or you'll beat me to it :p Basically I'm porting my old terrain renderer that was last seen in OpenMW 0.36 (Ogre3D) but with a few twists to take better advantage of OSG capabilities. Loading the terrain should hopefully become buttery smooth with no frame drops in between transitions.

LOD distant objects (which people commonly confuse with 'distant land') is a completely separate feature, you're welcome to work on it.

Most of the items on your list should be done with (or supplemented with) modding, though some groundwork in the engine will be required as well. I was thinking we could integrate the EffectCompositor OSG snippet which would allow us to define any shader/compositor in an XML file for the engine to load, the user can then pick and chose a list of compositors he wants to use and we're off.

1) Deferred shading system, so we will get essential support of unlimited light sources. Also in perspective it could improve the look of magic system, because we may turn every particle into a small light source)

A problem for deferred shading is the large number of semi-transparent objects that MW has, which will have to be rendered on top in a non-deferred pass. If you took a random screenshot of the bitter coast literally half the screen is covered with semitransparent fauna.

Secondly, as weird as it sounds, some areas in the game actually depend on per-vertex lighting to not look bad (for example the ghost fence, and the fire place in the chargen room). Of course, these could be changed, but requiring someone to go in and change all these lights.

Bluntly speaking, I don't think DS would work very well for the vanilla game but it certainly might with enough mods.

I'm curious, though, if DS would do anything to improve performance (right off the bat with vanilla files, that is). Currently, the forward lighting system is a huge bottleneck in some scenes, because we have to sort all objects by their light list and render each light list separately.

GPU skinning

MW meshes have so few vertices yet so many bones that GPU skinning isn't going to improve anything. In fact when I tested the osgAnimation hwskinning implementation I seem to recall it made the performance worse. Could be useful for modded stuff but not a huge priority right now.

3) Light maps at least for Sun, for many sources in perspective (to be honest I do not know how to provide good performance here, but it seems possible because of games like S.T.A.L.K.E.R. was already support unlimited shadow sources something like ten years ago!)

Are we talking about shadow mapping here? Do you have any experience with osgShadow or would you write a custom framework?

2) HDR

HDR may need lots of fine tuning to get it to look good with all the textures and regions in the game but please try, I'd love to see it

physical-based shading

This will require all models in the game to be updated to actually use physically based shading parameters. Far off in the future but nice to have, sure. You may want to consider making the shader compatible with the PBR that Hrnchamd is working on for MGE-XE.

Since we're talking about HDR and PBR I would also add gamma correct rendering and ambient occlusion to that list, what do you think?

Thank for replies and for support

@psi29a, of course distant land is a great feature, I very want to see it as most people, but I just want to start from something "habitual" Thank you for link, I'll try to observe current situation

@DestinedToDie yes, in theory simplified landscape and mipmapped textures already could give possibility to render world at big distance, but good automatic LOD for objects surely could be a problem =( But of course it will be discussed when we will arrive to implementing it It's surely interesting, but lets first look how it will going

@scrawl, if you will find at least a bit of time for project, maybe we will continue your work? =)
Of course I still don't know most of details around renderer, but will try to learn

scrawl wrote: I was thinking we could integrate the EffectCompositor OSG snippet which would allow us to define any shader/compositor in an XML file for the engine to load, the user can then pick and chose a list of compositors he wants to use and we're off.

Thank you very much for pointing me at this library, It seems I was thinking about something same

Right, with semitransparent objects we need different approach, it could be some problem. Also It's undoubtedly that some game data could work not very good with advanced rendering. At least level designers and artists was tune their content for existing engine with specific capabilities. But I hope we could at least try to get something new. Maybe new scenes will not look so fancy as they can be with special created art, but with modern techniques it could look at least interesting And if once OpenMW will support all features we have a chance that some mods could add good game resources.
I hope it will be suitable also for PBR: the additional data for it is a roughness, metalness, normalmaps etc, but default parameters could give interesting results too, because light model itself is more complex.

Of course I'm not so sure in success as it could look, but I think it's interesting at least to try

scrawl wrote:Are we talking about shadow mapping here? Do you have any experience with osgShadow or would you write a custom framework?

yes, first that I thought is a simple shadow mapping. No, unluckily I was not use osgShadow, but I know that in our company's project shadows was implemented in plain OSG, without that extension. But I don't know the reasons. In theory simple shadow mapping is preety simple technique, also it could be extended as cascaded shadow maps etc. But what on practice with OSG - I don't know. As my collegue said, most hard thing for him (when he implement the shadows) was good algorithm to choice the area (and a projection matrix for shadow map as a result) which will be covered by shadowmap. If we could use some inaccuracy(and so will lose part of shadow map area to unvisible shadow), it should not be easy.

Yes, I'd like to see HDR's effect too Besides, if it will not look good, it could be disabled of course But I think it's very important to use real (or more or less same as ... ) photometric light's brightnesses. It' s an issue, because we only have the light's radius and maybe attenuations, but I think we could calculate it by some way (it could be enough to solve equation like "brightness / (C + d * L + d^2 * Q) = const"

scrawl wrote:Since we're talking about HDR and PBR I would also add gamma correct rendering and ambient occlusion to that list, what do you think?

Totally supports Also I have some thoughts about screen-space reflections, but it could be implemented later, if we will provide the framework for complex rendering techniques.


But I still don't know what way should I select. Most good way could be separating the renderer and providing our "super-mega new renderer with new features"(even in that case I won't just drop old code, I just want to rewrite some parts of it. Totally replace fixed pipeline to shaders, provide support of modern OpenGL core profile (so that OpenMW could be debugged and profiled with help of tools like nSight and gDebugger)) as separate part of OpenMW, or try to keep old approach and just try to gently add new features to it...

And just another about original game content. Here is a normals visualization:

Spoiler: Show

It looks preety strange that some normals are distorted a bit. For example please take a look at the carpet, it should be flat and green, because it's surface is horizontal relative to the viewer, but... Also something incorrect with the ceil at the front of the viewer.

Could it be a bug with models import? Or maybe it's some kind of my mistake, or in worst case the original normals isn't so good? O_o

No, that's expected, the models just have crappy normals. I forgot about that, it may make it difficult to achieve good AO. I guess we have another reason to overhaul models before we can really make proper use of new techniques.

Forward+ seems like a much better fit the Morrowind content. It's basically a forward renderer which is culling the light sources in a compute shader. The implementation is in Vulkan, though. Not sure if there really are benefits with OpenGL because the driver probably won't be able to to figure out the exact dependencies that you can specify in Vulkan. It would also require a driver with compute shaders.

@scrawl
In worst case we could think about computing the image-based normals (with help of functions dfdx and dfdy), but it will be flat... Maybe some techniques to get smooth image-based normals is exists, but it could be a problem anyway

@swick
I'm not sure but it looks like proof-of-concept project. A big part of renderer is not just lighting, but materials, animations, LOD and management of it, nut I'm not sure is that present here. But surely Vulkan itself is very good thing in experienced hands It's very interesting to learn it in nearest future.

Scrawl and New-graphics-programmer-guy (aka allcreater) in the same thread, discussing future graphic feature implementations.

Best thread in years.