Advanced rendering

[psi29a]

One of these days, in between work, raising a child, learning python, C++ and the basics of recombinant genetics, I'll get around to spending some real time with glsl.

I feel you there, 4 children, work and house renovations here.

[magamo]

One thought I had, is I've looked at some of the LOD stuff a little bit in OSG, and it seems to have a pretty good algorithm for computing simplified meshes on the fly. I know Destined doesn't particularly think it's the way to go, but part of me wants to advocate for it, so that all mods past, present and future, will be supported without needing LOD specific updates for OpenMW from every mod author, which would leave a whole lot of them looking bare from a distance, especially since I suspect that distant terrain will be autogenerated (As it was in pre OSG OpenMW). Having this be handled by OpenMW would also save users from a very technical and error prone step as it could be in MGE.

[AnyOldName3]

If autogeneration is an option, we should still allow it to be turned off, and also allow some mechanism for modders to create LOD meshes to be used instead when appropriate. It almost certainly wouldn't get merged if it was always on, made certain things look wonky, and/or was too inflexible to allow a 'better' solution to be used where appropriate.

[damiel]

Last I heard, Damiel was working on it too. A big part of the problem is that the shader really wasn't designed to be used on close ranges, and is probably something worth looking at when distant terrain is reimplemented. For me, that fog shader to cover long distances with distant terrain would be a very good stopgap until LOD objects are implemented. It'd be awesome if the original author of the shader, visvaldis were to return to work on it too. One of these days, in between work, raising a child, learning python, C++ and the basics of recombinant genetics, I'll get around to spending some real time with glsl.

Yeah i was looking the shader a while ago, but my work on this things is also kind of stop-and-go, because i have to learn a lot of new things on my way. The only thing i did regarding this shader was to pull out the changes visvaldas did in the water implementation to load shaders. This little piece of code is already a nice win as it eliminates the need for anybody whos interested at working on this to carry over the only patch of visvaldis that actually touched the engine code, so you only need to carry over the shader files itself. Take a look at this commit: https://github.com/OpenMW/openmw/commit ... 0c8ff59c72

[visvaldas]

Last I heard, Damiel was working on it too. A big part of the problem is that the shader really wasn't designed to be used on close ranges, and is probably something worth looking at when distant terrain is reimplemented. For me, that fog shader to cover long distances with distant terrain would be a very good stopgap until LOD objects are implemented. It'd be awesome if the original author of the shader, visvaldis were to return to work on it too. One of these days, in between work, raising a child, learning python, C++ and the basics of recombinant genetics, I'll get around to spending some real time with glsl.

Yeah i was looking the shader a while ago, but my work on this things is also kind of stop-and-go, because i have to learn a lot of new things on my way. The only thing i did regarding this shader was to pull out the changes visvaldas did in the water implementation to load shaders. This little piece of code is already a nice win as it eliminates the need for anybody whos interested at working on this to carry over the only patch of visvaldis that actually touched the engine code, so you only need to carry over the shader files itself. Take a look at this commit: https://github.com/OpenMW/openmw/commit ... 0c8ff59c72

viewtopic.php?f=6&t=2905&start=50#p45492

[magamo]

If autogeneration is an option, we should still allow it to be turned off, and also allow some mechanism for modders to create LOD meshes to be used instead when appropriate. It almost certainly wouldn't get merged if it was always on, made certain things look wonky, and/or was too inflexible to allow a 'better' solution to be used where appropriate.

The way I would think the mechanism could work, is modders could override LOD meshes by putting in the mesh filename something like '_lod_X' where the X was the osgLOD level the mesh was meant for. And if the '_X' were omitted, the '_lod' mesh would be used for any levels where an '_X' mesh was not present. Basically the same manner for which modders can create normal and diffuse maps for various textures now. As for 'turning off autogeneration', perhaps a mechanism where the generated meshes could be cached to disk, and they only get updated when a mod(s) containing said mesh has a newer timestamp on the containing mesh file or BSA than the cached mesh. That way once the library was built, it would only really 'waste' CPU cycles when something were updated.

[Br0ken]

Another option is Clustered Forward Rendering, used by Doom4 (viewtopic.php?f=4&t=3787).

I read a bit about this stuff, looks like a quite interesting approach. And it can be done even with OpenGL 2.0 (according to Ola Olsson, author of this method). Nice compilation of readings: http://efficientshading.com/2016/09/18/ ... -the-wild/