New Renderer (OpenGL 3.3)

Glad you guys like it!

@Freestalker.fr:
My goal is to have a file where you can change each value per texture so that there is a material system. The only bad thing about this is, that you have to change everything manually. I would rather have some automated process when the model gets exported from Max or smth. But for now I focus on a version which can get expanded later after release.

@eigos:
I plan to create a mod on ModDB so everyone can incorporate it into their mod. The goal is to keep FL alive after all. Though I am thinking about first testing it on the mod I am maintaining because it is easier to get feedback and deliver updates.

I can’t say when it is going to be finished. Currently I am working on polishing stuff and you never know when all the problematic bugs are gone. At least I can say it is working on AMD, Nvidia and Intel graphic cards. Hopefully I can finish it this summer.

Regarding the modifications: I only scaled up the vanilla textures and applied some filtering to make them look less blurry. Besides of that .mat files are not changed. The models need some more informations (TBN data, like the Max .cmp exporter writes) and that’s all. I have a batch process which adds the data to original models. Additional textures (height and normal maps with baked in self shadowing) are loaded from separate folders depending on the diffuse texture name. But I am currently working with .Nx to test more additional maps. We will see with what we’ll come up with.

So for those who enjoy my videos here are two with the current state:
http://www.flnu.net/downloads/fl0807.mp4
http://www.flnu.net/downloads/fl0807li.mp4

Lots of internal fixes, fixed pipeline is gone (all shader now), optimizations and real post processing. I also added ambient occlusion maps. Plus I decided to scale down the ambient light intensity, since it is quite high in standard FL.

Still some work left, though. Feedback is welcome!

As always the stutters come from running FL server and FL on the same machine.

Yeah I really like to look, too At certain places I am even surprised how good it looks now. I am still working on improving it, though. I decided to ignore point lights since it is really expensive to cast shadows for those (and I have not implemented them). Here is a video from NY without the point light at the planet: http://www.flnu.net/downloads/fl1007.mp4

Skotty and I think it is still ok. Other places look even better, because the missing shadows made it look strange.

I plan to automatically do some stuff for planets anyway so it should not be needed and also look better later on.

Regarding the heightmaps: You’re right, vector format is always better. I’ll see what I can do.

Also two nice screenshot I took while testing:

Hehe, I know I am teasing you, but here are two more videos where I really liked the look:
http://www.flnu.net/downloads/fl12072.mp4
Here this model is not modified, meaning only diffuse maps:
http://www.flnu.net/downloads/fl1207.mp4

Regarding the specularity: Since this is partially a PBR renderer, you have a BRDF and thus a roughness and metalness parameter for each material (also there will be some more like specular intensity for the environment maps). Currently I only know which model and texture is being rendered, so until we reverse more there will be a file where you can set all these values for each texture name (the names are taken from the .mat etc. utf nodes). I will try to make it not a pain to edit and preview those values

There is quite a lot material out there e.g. https://learnopengl.com/#!PBR/Theory in the end there are some maps mentioned (I don’t have implemented all of them and there are a lot more possible maps). Currently I calculate the roughness from the luminance of the diffuse map in the shader, if there is no existing roughness map. You’re probably not interested in the math part, but there is also other interesting stuff in the article.

Keep in mind that there is not “the” rendering technique. My solution is also a variation of different techniques combined, which is not unusual.

Regarding the material values: I think that I can create a program with a preview ( I already have a renderer which can load the cmp and mat files etc.). But its possible that I postpone that for after the release of the wrapper.

Btw. shadows have been there quite early and it is also one of the last things on my list: I want to exchange them for a better shadow rendering technique.

Ah I see, but it’s just from the normal shadow rendering. So nothing new here The new technique should only create sharper edges and a larger shadowed area (it’s quite limited right now).

I was referring to the math in the same article, but if you are familiar with all those expressions here is a nice article which goes into more detail: http://renderwonk.com/publications/s2010-shading-course/hoffman/s2010_physically_based_shading_hoffman_a_notes.pdf

Regarding the maps: The names are a little bit problematic because often e.g. the name bump map is used for a normal map but there are also the old dot3 bump maps (which are greyscale). So to prevent misunderstandings you always have to make sure what map the author exactly is meaning with the name. Glossiness and roughness map can also be the same because 1-roughness is usually glossiness. But there also is specularity, which can be converted to glossiness etc., which again depends on your lighting formula. So you really have to pay attention.

It makes sense to mix height and normal maps because then you can put all the fine details onto the normal map and the real visible height difference go into the height map. (This is how I do it plus the normal maps are a variation of valve’s ssbump maps so that they have self shadowing baked in using the appropriate height map). I will explain all the maps I use when the wrapper gets released (there might still be changes until then).

Usually I test the specific map and if the benefit is not high enough I don’t use it. But I am open for suggestions, even after the release.

Actually, I already compress the normal maps with ATI2N format and the height maps have ATI1N. So it is the smallest it can get. But you’re right you could use maps for different purpose, as long as the texture compression doesn’t stand in the way.

I see that you have some knowledge about the topic and especially the mathematic background (which is good). Of course it is more physics, but the used tool is mathematics Maybe once it is released you can try to experiment with the shader code of the wrapper to test different lighting models out, if you are into that stuff. There might be even a better looking one than I use now.

Also there are emissive maps: FL uses them, so they are availlable.

Yeah, pm is better. I am currently learning for an exam next week so not much time either.