Since the shader source was open, sometimes I need to access some variables that are not in the original shader.
For example original shader contains:

So which registers contain world, view, model and other matrices and variables that can be accessed?
This question is addressed to Scawen, because I suppose no one else can answer.

EDIT:

Quote from Scawen :

If you could tell me, on your thread, exactly which extra data you need, maybe I can make a note to see if it can be included in my planned update.

Model * view * projection matrix.
Model * view matrix.
View matrix.
Projection matrix.
View * projection matrix.
Transpose of model * view matrix.
Inverse transpose of model * view matrix.
Model matrix.
Inverse of current world matrix.
World space position of the camera.
World normal.

Last edited by Keiichi_Tsuchiya, Sat, 22 Nov 2014 11:36.

By the way, since the texture require rework, I will try to pack HDR data there to get rid of the fake fresnel effect like is was in original textures. Unused alpha channel allows me to do that.
But there's huge problem with static objects that have reflection and haven't shader source (like windows in the buildings).

I tried to fix spherical projection mapping and found an intesting method that really works.
First of all, I captured a new texture to reflect environment in the new way:

After all transformations i got new sphere map which have a data below the horizon compared to the default one.
Default:

New:


Now lets go to the shader.
The old one have pretty simple calculations an looks something like this:

New one looks like this:

and difference is HUGE
Comparing screenshots(reflection only with new texture):
Old:

New:


So now we have a reflection which quite similar to the old but without this mirrored bottom issue.

The main problem is that now I need to remake all reflection textures.

EDIT:
I've found that i was mistaken and used object normal instead of world normal, but it doesn't matter because this affects only during rotation of the vehicle.

Last edited by Keiichi_Tsuchiya, Tue, 18 Nov 2014 17:44.

Realtime reflection is not possible with shader only. It requires to render environment to cubemap texture and only after that we can apply this texture in the shader.

Well, multiplication of reflection by a specular is not quite correct solution, because after this calculations reflection will be visible only where is specular lighting is bright.
But surface should reflect environment almost everywhere.

Problem with this reflection in it's initial implementation. It's a hemisphere which in a bottom absolutley the same as on top.
By a default there was a solution for this in shader but I slightly eased it to have more work around with fresnel effect.
You can find the line
float3 Ref = envmap_col.rgb * min(1.0,In.EnvA.x+0.5);
and just remove this addition by 0.5. instead of rewriting final color blendings.
On the screenshots you can see the difference.

I thought about creating an alternative skin viewer, with good graphics, different environments and lighting conditions but there is too much work for one person to create it quickly.
In any case, if there is someone who is interested in this idea and can work with 3D editors and texturing, we can collaborate and make it happen.

Quote from DANIEL-CRO :

That would cause inconsistent physics. For example physics wouldn't run the same at 10 FPS and 300 FPS.

No, it's not. In this case there will be all the same 100 Hz. Interpolation only works with the visual part. There are many physics engines that use this method (Physx, Havok, Box2d, etc).
I give an analogy:
Main artist painted two keyframes of cartoon, and asks an assistant to draw the intermediate frames.
Only the main artist is responsible for how the story goes (physics steps).
Assistant can only show what is going on between the keyframes (interpolation).

Quote from Scawen :

I'm not sure but I think that is because the physics updates are at 100 Hz but the frame rate is at 75 Hz. So there are 4 physics updates every 3 graphical frames. That means you have 2 frames with one physics update each and then one frame with 2 physics updates in it.

There is a possible solution for this but I'm not planning on tackling it soon because it's hard to do and there are higher priorities. That involves storing states of all cars and world objects between physics updates so that a frame can be displayed at times other than at the 0.01 second intervals.

I thought that interpolation of physical steps is a fairly simple thing.
Accumulating time since previous step, storing two states and interpolate between according to framerate and time.

Since LFS moved to DX9, I wondered, what level of quality can be achieved at the current 3d low poly content if potential of shading will be used at maximum power.
So I decided to do a little experiment.
I completely re-did most of RaceAbout textures according to modern standarts and rendered it in Unity Engine with my PBR shaders.
I purposely didn't touch geometry, and left all sharp edges and bugs of 3d model to show all mistakes of current models.

Here's some screenshots and a link to Web Player (45MB).
May not work properly on intel integrated GPUs

https://faf42552090c8fb619b8a6 ... 1JUMEloaWs/RaceAbout.html

Quote from Scawen :

My vague thoughts are to implement, as a first stage, three shaders for cars: paint / matt / glass. These are easily detectable for all cars without needing to start getting detailed in the editor.

_

I think it is too early to create a shader scene until we get a stable patch.
After few test patches Scawen will separate shaders to glossy\glass\matte, so it have to rewrite all of it.

Quote from lfsrm :

interesting but what is that ? a simulator or a simple graphical engine ?, btw look like you using assetto corsa mclaren, right ?

it's a simulator which I hope to release someday.
And yes, there's Mclaren from AC which i'm using for testing purposes (scripting, rigging, shading, texturing, etc) because of convenient texture UV. Everything will be replaced when my buddy will finish original 3d content.

Last edited by Keiichi_Tsuchiya, Tue, 5 Aug 2014 19:49.

Quote from THE WIZARD DK :

i tried yours. im sure it looks great on other machines. but when i use it. all surface joints gets pixelated. like the boot / hood of any car is with squares on the lines thats supposed to be smooth..

Can you attach an example? I have not yet received any bug reports, so it is not surprising that I could miss something.

If you mean the sharp edges with specular lighting, then there's nothing I can do, since it depends on the detail of a polygonal mesh which is really poor.
There are 2 ways to fix it:
Modification of .VOB file with higher mesh detalisation, which is not quite a legal, or additional textures for materials so i could add normal maps for smoothing edges and adding details.

Anyway i can do really something beautiful, if i had more access to LFS graphics.

For example, I have attached screenshots of one project which I'm working on.
All graphics is realtime(exept the motion blur).

Last edited by Keiichi_Tsuchiya, Tue, 5 Aug 2014 19:02.

In defense of DX9, I can say that it's even hasn't used at half of potential power.
So DX11 support is pointless at the moment.

As far i know there's no problems.
You can do shader fallback according to user's gpu anyway.

Quote from Scawen :

We need to compare the "same" lighting effect, in one case optimised by doing most of the calculation at the vertex, and in the other, doing all the calculations at each pixel.

Here we go



By the way, a specular reflection on Flame's screenshot was created using vertex normals

Quote from Scawen :

When I see sqrt and pow in a pixel shader, I'm nearly falling off my chair with the shock. But maybe I am just a relic from the 80's.

I thought that you care about optimization, but I even could not imagine that so much

Last edited by Keiichi_Tsuchiya, Thu, 24 Jul 2014 16:58.

Quote from Scawen :

Note, the default reflections (environment map textures) are made a lot darker than the sky, so that the highlight can be strong and the reflections are at a reasonable level for a non-fresnel shader.

I completely forgot about it.
Anyway, if the environment textures require rework, maybe it can be replaced with cube maps? It can also be converted into a RGBM(http://graphicrants.blogspot.r ... /rgbm-color-encoding.html) format to lay the foundation of HDR features.

I wrote a post about some graphic opportunities and techniques
https://www.lfsforum.net/showthread.php?t=86111

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 =)

Last edited by Keiichi_Tsuchiya, Sat, 26 Jul 2014 22:52.

Quote from sinbad :

Not wishing to be critical, but to me the right hand pics in both cases have paint which looks more metallic than in the one on the left. The left hand pic looks flat in comparison.

Here's a more obvious example

I brought you some shaders, guys.
It were been writted a little bit dirty, but lighting now is per-pixel, and I added some other things. In a nutshell it is metallic paint
There's some screenshots below(left is new, right is old)

Last edited by Keiichi_Tsuchiya, Wed, 23 Jul 2014 00:59.

Whoa... Shaders now open. Thank You, Scawen!

Quote from 5tag :

Those stairs though :P
By the way on that last picture, you don't need to blur/distort these reflections.

I realized this only after I finished editing.
Anyway, I found an excuse.
In windy weather, and with a slow shutter speed, sometimes it happens:
http://blogs.capecodonline.com ... phy/files/2010/03/b11.jpg

Last edited by Keiichi_Tsuchiya, Thu, 26 Jun 2014 21:13.

some shots with realistic motion blur (technique similar to gt5/gt6 photo mode)
http://img.leprosorium.com/2012600
http://img.leprosorium.com/2108567
http://img.leprosorium.com/2050878
and experiments with ambient lighting
http://img.leprosorium.com/2137535

Last edited by Keiichi_Tsuchiya, Mon, 30 Jun 2014 06:24.

Quote from Becky Rose :

Pre-baked Lightmaps are complicated in the LFS arrangement, although are possible... but they would curtail any hope of a day/night cycle.

Actually no. There's some trick with lightmaps. You can bake only skylight high quality GI with white color and multiple it however you want in shader. Combine it with realtime directional light/shadows and you'll get a nice look. Of course there's no sunlight GI, but making some low-res bounces in realtime is not so costly than whole GI

Anyway, we don't know what Scawen will do. But if shaders will be open, I'll be glad to help make LFS beautiful.
There's picture's from project i'm currently working on with couple friends
https://dl.dropboxusercontent.com/u/88855479/mp412C.jpg
https://dl.dropboxusercontent. ... 479/screenshot_sunset.jpg

Last edited by Keiichi_Tsuchiya, Mon, 23 Jun 2014 00:46.

Quote from Amynue :

While new Westhill looks great, I can't help to notice that there is one thing which looks rather awful. It's the shadows. I mean, look at this:
http://i.imgur.com/65GaXQx.jpg
With red I've marked the shadows which look either weird or out of place. Yeah, that's like 80% of all shadows in the picture.

Some objects on the other hand don't have a shadow at all. Like cones and bilboards in here: http://www.lfs.net/page_images/screenshots/WST006.jpg

Westhill is still in developement, so it may improve, but if we take a look at existing tracks, it doesn't look any better:
http://i.imgur.com/d49ujMP.jpg
http://i.imgur.com/o2Qlh7P.jpg
http://i.imgur.com/xx1Tdcp.jpg

So yeah, are there any plans to improve track shadows? I wouldn't prioritize this over finishing the tyre physics - but then again - I have no idea how much time would it take to implement better shading system for the tracks.

It's vertex prelight. Shadows are simply baked into vertex color.
This is an old technique, where quality of lighting depends on detail of the mesh.
vitaly_m, baked lightmaps was not possible because old tech limitations. I hope it will be fixed with Shader Model 3.0 and pixel shading.