Well, now LFS is using DX9, so why not to discuss all visual opportunities that may be implemented. Currently lfs is still using a lot of "old school" techniques which can be improved and redone with new shader model.
I'm going to list the things that in my subjective humble opinion could fix the situation and improve the visual component.
First of all there's things that i call necessary (I mean it's a realy shame not to use it. This is the first that comes to programmer's mind who works with modern graphics API)
•LightMapping.
We all know how lighting looks like in LFS. It's called vertex prelight.
Baked light affects only the vertices so all direct and indirect shadows wrong, ragged, and depend on the detail of a polygonal mesh.
With the simple addition of UV2 to mesh, baking lightmaps to texture(in v-ray for example), and blending textures in the shader should not be a problem.
•Cubemapping
Cubemaps are designed for environment mapping. It's native supported by any modern GPU and works perfectly well. I don't know why LFS still using sphere maps to reflect the environment, which stretched, distorted, without a bottom.
The same applies to the skybox
•Specular Lighting(microfacet distribution)
Currently LFS uses only 2 ways to reflect directional light.
Diffuse and diffuse + environment mapping.
But in the real world, almost all surfaces reflect light with different strength and roughness. Asphalt slightly reflects the sun, but the small stones in this asphalt reflect light a little harder. Leather in car interior, plastic materials, metallic surfaces: all of this have a specular reflection.
By adding blinn-phong or more modern lighting model like GGX, you can greatly improve the visual quality.
•Normal Mapping
With normal mapping you can add a lot of detail to the objects without any poligonal cost.
Bumps and cracks in the asphalt, metal flakes in the car paint, shallow grooves in the leather panels and car seats. Even light dents on the car body. All illuminated from different angles, and adds depth to surface.
_______________________________________________________________
Let's move on to more advanced things. This is the standart in modern AAA games.
Things that should be used if Scawen wants to make lfs looks photorealistic like GT6/Assetto Corsa/PCars.
•Realtime shadow mapping
There are many situations where lightmaps useless because of its static nature.
Dynamic change the time of day, weather, direct shadow of the car inside the cabin. To do all this requires dynamic lighting and shadows.
If Scawen plans (as far I know he does), the dynamic changes in the environment, without dynamic shadows it's no possible.
But then there is a problem with lightmaps that become useless in the dynamic light and shadows.
It will be necessary to replace lightmaps to the global illumination(Occlusion) maps only for indirect light from the sky. And some cheap per vertex real-time GI technique for light bounces from directional light.
Overall, there are many different techniques for casting shadows, so it is not very big problem.
•High Dynamic Range Rendering
I'll try to explain as simply as possible.
Look at this picture.
http://upload.wikimedia.org/wi ... ons/b/b3/HDRI-Example.jpg
Depending on the exposure we can see or stained glass, or a room within the church.
This is because in the real world range of brightness is much higher than the screen can display or usual picture can carry.
Currently LFS has a low range, it is easy to see it in dark places like under bridges and in the pits on some racetracks.
HDR usually contains complete information about the brightness and color, which can be adapted for display in "exposure" post-effect.
HDR refers not only to show the picture on display. It concerns how light affects the surfaces, not only diffuse lighting, but specular lighting and environment reflection maping.
Also, if we take changing time of day as an example, the difference of lighting does not fit in the normal (256 steps in ordinary 8 bit per channel picture) range, so we need to deal with HDR.
•Camera render to cubemap.
It's about realtime reflections on the car.
Just capture turns 6 sides with one 90° fov camera to cubemap render texture, in the center of car(excluding it from rendering) and use it as reflection. It also allows to make dynamic indirect illumination for car(More in PBR bellow).
•Physically Based Rendering(PBR)
Do you want to know where moving game industry, and where goes all the computing power of new PS4 and Xbone?
This standardized shader system, which allows to show the most realistic surface, and save time to artists.
The basic rules are:
—All surface parameters should preferably be taken from real sources (scan data)
—The surface should not reflect more light than was received.
—Diffusion of light now combined with environment map, so environment maps are "blurred" according to microfacet distribution
—Any surface will reflect specular light anyway (more or less)
—Fresnel "effect" on everything.
More about PBR here:
http://www.marmoset.co/toolbag/learn/pbr-theory
http://www.marmoset.co/toolbag/learn/pbr-practice
With point light sources there are no problems in terms of implementation, but with the environment map and its diffusion may appear questions.
There are 2 ways to do this: pre-bake and in real time.
In the first method, you can perform all mathematical calculations in advance and bake it in a static cube maps. In shader just smoothly change the cubemap lod.
http://seblagarde.wordpress.co ... ysically-based-rendering/
In the second method you should do cubemap impotrance sampling in shader for specular reflection http://http.developer.nvidia.com/GPUGems3/gpugems3_ch20.html
and use Valve's ambient cube for duffuse reflection http://www.valvesoftware.com/p ... gInValvesSourceEngine.pdf
•Linear color space
There's a whole story about the color space and gamma correction.
Long ago, in the early appearance of cathode ray tubes for televisions and monitors, there was one problem. The brightness was not correctly displayed on the screen, with dips in the middle parts of brightness.
http://filmicgames.com/Images/ ... ntro/GammaLines-Small.png
Controllers for gamma correction declared unprofitable and the decision was to change the gamma directly on original images.
Now all the screens are LCD, but still use the old gamma-correction rule for compatibility.
It would have meant nothing, but there is a caveat.
All calculations that occur in a shader is already happening with the modified gamma correction. From the physical point of view it is not right, and it can be seen in many games where the light unrealistically is too bright or too dark in different situations.
To solve this problem, it is necessary to translate all input values into a linear color space, and only after all calculations are done, before displaying translate everything back to gamma color space.
_______________________________________________________________
And now some about the post-effects.
I will list only those that are worthy of attention, and will not be superfluous.
•Tone Mapping
Necessary with HDR rendering.
In simple terms, it works like a exposure meter in the camera, evaluates brightness and adjusts the exposure so that the player can see what is happening on the screen.
•Glow/Bloom
Thing is not necessary, and requires HDR to display correctly.
Creates a small "halo" around bright areas of the image. If used correctly, it will make picture a little bit more "photorealistic."
•Lens flare
All that we see on the screen - either real images taken on camera or graphics drawn by people. I mean that we will never see that picture on the screen, which we see with our eyes.
Why not add an effect that perfectly imitates the camera lens.
•Screen Space Local Reflection
This is a complicated effect that allows you to create a real-time reflection on the surface of any shape. The main advantage lies in the fact that, compared with other real-time reflection techniques not required to render the scene twice.
Works perfectly well if combined with PBR.
I think that's all I like to suggest, even if it looks too optimistic.
Something can be described is not entirely correct, but I hope that in nothing I was not mistaken.
And sorry for my english =)
I'm going to list the things that in my subjective humble opinion could fix the situation and improve the visual component.
First of all there's things that i call necessary (I mean it's a realy shame not to use it. This is the first that comes to programmer's mind who works with modern graphics API)
•LightMapping.
We all know how lighting looks like in LFS. It's called vertex prelight.
Baked light affects only the vertices so all direct and indirect shadows wrong, ragged, and depend on the detail of a polygonal mesh.
With the simple addition of UV2 to mesh, baking lightmaps to texture(in v-ray for example), and blending textures in the shader should not be a problem.
•Cubemapping
Cubemaps are designed for environment mapping. It's native supported by any modern GPU and works perfectly well. I don't know why LFS still using sphere maps to reflect the environment, which stretched, distorted, without a bottom.
The same applies to the skybox
•Specular Lighting(microfacet distribution)
Currently LFS uses only 2 ways to reflect directional light.
Diffuse and diffuse + environment mapping.
But in the real world, almost all surfaces reflect light with different strength and roughness. Asphalt slightly reflects the sun, but the small stones in this asphalt reflect light a little harder. Leather in car interior, plastic materials, metallic surfaces: all of this have a specular reflection.
By adding blinn-phong or more modern lighting model like GGX, you can greatly improve the visual quality.
•Normal Mapping
With normal mapping you can add a lot of detail to the objects without any poligonal cost.
Bumps and cracks in the asphalt, metal flakes in the car paint, shallow grooves in the leather panels and car seats. Even light dents on the car body. All illuminated from different angles, and adds depth to surface.
_______________________________________________________________
Let's move on to more advanced things. This is the standart in modern AAA games.
Things that should be used if Scawen wants to make lfs looks photorealistic like GT6/Assetto Corsa/PCars.
•Realtime shadow mapping
There are many situations where lightmaps useless because of its static nature.
Dynamic change the time of day, weather, direct shadow of the car inside the cabin. To do all this requires dynamic lighting and shadows.
If Scawen plans (as far I know he does), the dynamic changes in the environment, without dynamic shadows it's no possible.
But then there is a problem with lightmaps that become useless in the dynamic light and shadows.
It will be necessary to replace lightmaps to the global illumination(Occlusion) maps only for indirect light from the sky. And some cheap per vertex real-time GI technique for light bounces from directional light.
Overall, there are many different techniques for casting shadows, so it is not very big problem.
•High Dynamic Range Rendering
I'll try to explain as simply as possible.
Look at this picture.
http://upload.wikimedia.org/wi ... ons/b/b3/HDRI-Example.jpg
Depending on the exposure we can see or stained glass, or a room within the church.
This is because in the real world range of brightness is much higher than the screen can display or usual picture can carry.
Currently LFS has a low range, it is easy to see it in dark places like under bridges and in the pits on some racetracks.
HDR usually contains complete information about the brightness and color, which can be adapted for display in "exposure" post-effect.
HDR refers not only to show the picture on display. It concerns how light affects the surfaces, not only diffuse lighting, but specular lighting and environment reflection maping.
Also, if we take changing time of day as an example, the difference of lighting does not fit in the normal (256 steps in ordinary 8 bit per channel picture) range, so we need to deal with HDR.
•Camera render to cubemap.
It's about realtime reflections on the car.
Just capture turns 6 sides with one 90° fov camera to cubemap render texture, in the center of car(excluding it from rendering) and use it as reflection. It also allows to make dynamic indirect illumination for car(More in PBR bellow).
•Physically Based Rendering(PBR)
Do you want to know where moving game industry, and where goes all the computing power of new PS4 and Xbone?
This standardized shader system, which allows to show the most realistic surface, and save time to artists.
The basic rules are:
—All surface parameters should preferably be taken from real sources (scan data)
—The surface should not reflect more light than was received.
—Diffusion of light now combined with environment map, so environment maps are "blurred" according to microfacet distribution
—Any surface will reflect specular light anyway (more or less)
—Fresnel "effect" on everything.
More about PBR here:
http://www.marmoset.co/toolbag/learn/pbr-theory
http://www.marmoset.co/toolbag/learn/pbr-practice
With point light sources there are no problems in terms of implementation, but with the environment map and its diffusion may appear questions.
There are 2 ways to do this: pre-bake and in real time.
In the first method, you can perform all mathematical calculations in advance and bake it in a static cube maps. In shader just smoothly change the cubemap lod.
http://seblagarde.wordpress.co ... ysically-based-rendering/
In the second method you should do cubemap impotrance sampling in shader for specular reflection http://http.developer.nvidia.com/GPUGems3/gpugems3_ch20.html
and use Valve's ambient cube for duffuse reflection http://www.valvesoftware.com/p ... gInValvesSourceEngine.pdf
•Linear color space
There's a whole story about the color space and gamma correction.
Long ago, in the early appearance of cathode ray tubes for televisions and monitors, there was one problem. The brightness was not correctly displayed on the screen, with dips in the middle parts of brightness.
http://filmicgames.com/Images/ ... ntro/GammaLines-Small.png
Controllers for gamma correction declared unprofitable and the decision was to change the gamma directly on original images.
Now all the screens are LCD, but still use the old gamma-correction rule for compatibility.
It would have meant nothing, but there is a caveat.
All calculations that occur in a shader is already happening with the modified gamma correction. From the physical point of view it is not right, and it can be seen in many games where the light unrealistically is too bright or too dark in different situations.
To solve this problem, it is necessary to translate all input values into a linear color space, and only after all calculations are done, before displaying translate everything back to gamma color space.
_______________________________________________________________
And now some about the post-effects.
I will list only those that are worthy of attention, and will not be superfluous.
•Tone Mapping
Necessary with HDR rendering.
In simple terms, it works like a exposure meter in the camera, evaluates brightness and adjusts the exposure so that the player can see what is happening on the screen.
•Glow/Bloom
Thing is not necessary, and requires HDR to display correctly.
Creates a small "halo" around bright areas of the image. If used correctly, it will make picture a little bit more "photorealistic."
•Lens flare
All that we see on the screen - either real images taken on camera or graphics drawn by people. I mean that we will never see that picture on the screen, which we see with our eyes.
Why not add an effect that perfectly imitates the camera lens.
•Screen Space Local Reflection
This is a complicated effect that allows you to create a real-time reflection on the surface of any shape. The main advantage lies in the fact that, compared with other real-time reflection techniques not required to render the scene twice.
Works perfectly well if combined with PBR.
I think that's all I like to suggest, even if it looks too optimistic.
Something can be described is not entirely correct, but I hope that in nothing I was not mistaken.
And sorry for my english =)
(despite looking otherwise xD)