Rendering for multiple viewports instead of one does not look like an increase of CPU load for me. Meshes, textures are sent once, shadow volumes are calculated one time...most things done three times are 100% on the GPU.
What increases the CPU load is the objects and texture count....but with 120 degrees FOV on one viewport this count is the same than with 120 degrees FOV 3 viewports.
Mirrors are done with an additional viewport...does it double CPU load?
....and mirrors take a LOT more CPU time than viewports because it doubles the object count. So you expect side viewports would take far less time to render than mirror because they cover the same FOV....no need to change scene like for mirrors.
Last edited by Juls, .
OK so I will never know. 
Filtered or not?
Where is the vector from car COG to driver's COG?
Long File of Secrets.
Filtered or not?
Where is the vector from car COG to driver's COG?
Long File of Secrets.
I will do a better version, with a config file. But later when I have time. This version does not only miss a config file...the maths are wrong, and it should connect with OutSim to get the best result.
This is already a dinput hook. It should work together with a d3d8.dll hook.
This is already a dinput hook. It should work together with a d3d8.dll hook.
If the drawing is correct (I mean it is not simplified and really works like that), and we consider oil is pushed only when openings are (at least partially) in front of each other.
Then the pressure received in the shaft is not anymore P, but (with some approximations, d small compared to D) P*2*d/(Pi*D).
So oil pressure required to obtain P0 in the center is now:
P=(P0+(v.R^2.w^2)/2)*(pi/2)*(D/d)
Then the pressure received in the shaft is not anymore P, but (with some approximations, d small compared to D) P*2*d/(Pi*D).
So oil pressure required to obtain P0 in the center is now:
P=(P0+(v.R^2.w^2)/2)*(pi/2)*(D/d)
Last edited by Juls, .
Euh just to unroll the thread.
I wonder if we can find the multiplier required if we take into account the fact that the hole receives oil only when it is in front of the oil entrance (at least partially).
Do you have an estimation of the diameter d of the hole? To chek if what I get can be useful.
I wonder if we can find the multiplier required if we take into account the fact that the hole receives oil only when it is in front of the oil entrance (at least partially).
Do you have an estimation of the diameter d of the hole? To chek if what I get can be useful.
Last edited by Juls, .
So the force on a slice of oil between r and r+dr is:
df=slice mass*r.w^2
= v.A.dr.r.w^2
This force should be compensated by pressure.
df=P(r+dr)*A-P(r)*A
(P(r+dr)-P(r))=v.r.w^2.dr
dP=v.r.w^2.dr
So if P0 is the oil pressure you want at the center
P(R)=P0+(v.R^2.w^2)/2
With R=0.0275, v=810, w=523
P(R)=P0+12.15 psi
This result assumes the hole is filled all the time with new oil, steady state which is not the case in your drawing. There should be a large safety multiplier. But it seems pressure has to vary with square of angular speed and square of radius.
df=slice mass*r.w^2
= v.A.dr.r.w^2
This force should be compensated by pressure.
df=P(r+dr)*A-P(r)*A
(P(r+dr)-P(r))=v.r.w^2.dr
dP=v.r.w^2.dr
So if P0 is the oil pressure you want at the center
P(R)=P0+(v.R^2.w^2)/2
With R=0.0275, v=810, w=523
P(R)=P0+12.15 psi
This result assumes the hole is filled all the time with new oil, steady state which is not the case in your drawing. There should be a large safety multiplier. But it seems pressure has to vary with square of angular speed and square of radius.
Yes but it was not so obvious. The projection matrix scales x, y and z, and calculates w using x,y and z. Later, x, y and z are divided by w.
I do not add a bias to z, but to w...
Haha, you are right. It looks like I managed to obtain a translated view without moving at all the view point. I explain:
In games, world coordinates are projected on screen. To do so, x and y coordinates are divided by z-> objects get bigger when they get closer (z->0)...infinitely bigger when z reaches 0 ->distorsion.
To moderate the distorsion, I change the projection matrix to divide by a*z+b (a,b positive constant). This is a mix between an orthographic projection (objects size unchanged with distance for a=0 b=1) and classic perspective (a=1 b=0).
Then when z->0, objects become larger but not infinitely.
I update the other components of the matrix to keep the same clipping planes, the same FOV far away, and I calculate a and b to get 3 times more things displayed on the nearest clipping plane.
And finally, as you say, the result is like looking from 25 cms back, but without actually moving the camera (I do not change anything in camera, only the final 3D->2D projection). Like being out of your body.
This is very strange, because if a=0 and b=1 then I have an orthographic projection which is a really very different projection without perspective. But as you say as soon as I introduce a very little part of perspective (a>0) it becomes immediately a full perspective projection, translated. I was trapped by this.
I suppose it comes from the way I mix perspectives, because many ray tracing programs use what they call weak perspective...a kind of mix between orthographic and perspective. Maybe it can not be achieved with a projection matrix like directx uses.
Fail. All this matrix stuff to get a translation...loss of time.
In games, world coordinates are projected on screen. To do so, x and y coordinates are divided by z-> objects get bigger when they get closer (z->0)...infinitely bigger when z reaches 0 ->distorsion.
To moderate the distorsion, I change the projection matrix to divide by a*z+b (a,b positive constant). This is a mix between an orthographic projection (objects size unchanged with distance for a=0 b=1) and classic perspective (a=1 b=0).
Then when z->0, objects become larger but not infinitely.
I update the other components of the matrix to keep the same clipping planes, the same FOV far away, and I calculate a and b to get 3 times more things displayed on the nearest clipping plane.
And finally, as you say, the result is like looking from 25 cms back, but without actually moving the camera (I do not change anything in camera, only the final 3D->2D projection). Like being out of your body.
This is very strange, because if a=0 and b=1 then I have an orthographic projection which is a really very different projection without perspective. But as you say as soon as I introduce a very little part of perspective (a>0) it becomes immediately a full perspective projection, translated. I was trapped by this.
I suppose it comes from the way I mix perspectives, because many ray tracing programs use what they call weak perspective...a kind of mix between orthographic and perspective. Maybe it can not be achieved with a projection matrix like directx uses.
Fail. All this matrix stuff to get a translation...loss of time.
Last edited by Juls, .
There is something wrong with your screenshots. There is no way I can get the same view with dll on and off, even with camera moved full forward. I think you somehow disabled the dll in both screenshots.
Here is the default LFS view, I chose FOV to match exactly the FOV from your screenshots (palmtree on the left, writing on the right). I have bigger horizontal FOV because I have different aspect ratio but we only look at horizontal FOV.
And second view with the DLL on, and camera moved full forward. No way it can give the same view. Notice how mirror is less distorted, how the windshield shape is more square too, and the windshield border does not hide the same part of the landscape than in previous view too. Notice how the short range ground changes between the two screenshots while far range remains unchanged.
Here is the default LFS view, I chose FOV to match exactly the FOV from your screenshots (palmtree on the left, writing on the right). I have bigger horizontal FOV because I have different aspect ratio but we only look at horizontal FOV.
And second view with the DLL on, and camera moved full forward. No way it can give the same view. Notice how mirror is less distorted, how the windshield shape is more square too, and the windshield border does not hide the same part of the landscape than in previous view too. Notice how the short range ground changes between the two screenshots while far range remains unchanged.
When you increase FOV, let's say to 120, objects far away shrink. It makes distances difficult to evaluate, cornering more difficult.
With this gadget, if you chose FOV 90, FOV is really 90 degrees far away, so track keeps it's normal size. But FOV increases close from the car. So you can see more on the sides like with 120 degrees FOV. So you have advantages of large FOV to see more on the sides, without inconvenients (far objects shrinking). Second advantage....objects are less distorted when they get closer from monitor side.
Last edited by Juls, .
Yes many problems with objects close from camera. Increase FOV or disable driver or move camera forward. That's why it is an experiment 
Perspective distorsion correction (useless experiment)
Edit: This is useless. Do not even try it. As crazy as it seems, the result is the same than moving the camera 25 centimeters backwards....but obtained without actually moving the camera.
Here is another experiment.
This dll introduces an FOV changing with distance.
Far away, FOV is the same as specified in LFS interface.
But as you look closer, FOV increases, up to three times for objects very close from the camera.
Advantages:
- you can see both mirrors from 60-70 degrees FOV instead of 90. At 80 degrees FOV you can see a lot on the sides like with 120 FOV, but track looks a lot bigger, not anymore like a tunnel.
Distance estimation is easier, far objects are easier to spot.
- it reduces perspective distorsion, car cockpit stretches far less when you turn your head.
Just unzip the d3d8.dll close from LFS.exe (save previous d3d8.dll if there is one there...maybe you have another similar mod...). Delete when you want to remove it. Does not change anything in LFS install.
Forgot to say...you have to disable Haze effect in Graphics for it to work properly.
Default view, 90 degrees FOV:
New view, 90 degrees FOV:
Far range FOV is still 90 degrees, but close range FOV is larger.
Camera position is unchanged.
For people interested, discussion about FOV:
http://www.lfsforum.net/showthread.php?t=27179
Here is another experiment.
This dll introduces an FOV changing with distance.
Far away, FOV is the same as specified in LFS interface.
But as you look closer, FOV increases, up to three times for objects very close from the camera.
Advantages:
- you can see both mirrors from 60-70 degrees FOV instead of 90. At 80 degrees FOV you can see a lot on the sides like with 120 FOV, but track looks a lot bigger, not anymore like a tunnel.
Distance estimation is easier, far objects are easier to spot.
- it reduces perspective distorsion, car cockpit stretches far less when you turn your head.
Just unzip the d3d8.dll close from LFS.exe (save previous d3d8.dll if there is one there...maybe you have another similar mod...). Delete when you want to remove it. Does not change anything in LFS install.
Forgot to say...you have to disable Haze effect in Graphics for it to work properly.
Default view, 90 degrees FOV:
New view, 90 degrees FOV:
Far range FOV is still 90 degrees, but close range FOV is larger.
Camera position is unchanged.
For people interested, discussion about FOV:
http://www.lfsforum.net/showthread.php?t=27179
Last edited by Juls, .
Thank you for your answers!
Yes I can to do that. From COG->Driver vector, angular speed and angular acceleration I get two additional accelerations I can sum. For the moment I use some arbitrary seat position. Even above the CoG, it gives strong additional accelerations (but horizontal in that case).
But derivating the angular speed vector (no angular acceleration in outsim) raises some little issues when you start or stop a session, as angular speed jumps to or from zero. I have to detect discontinuities, put thresholds, filter the derivative (derivating discrete time series introduces unwanted high frequencies, and filtering them adds some lag).
If there was a more straightforward way to do, it would be more convenient. I suppose LFS somehow calculates acceleration at driver level for head movements...so this data is directly available inside.
Last edited by Juls, .
OK still nothing. I was thinking about outsim acceleration data.
Maybe someone can help about that. I remember I asked for it one or two years ago and did not find the answer.
http://www.lfsforum.net/showthread.php?t=33581
Where does this acceleration come from?
1) Is it acceleration of the COG of the car body?
2) Is it acceleration of the car body at driver level?
Acceleration 1) is always smoother than acceleration 2) because it does not take into account car body rotations. For example when car is on tiny bumps like kerb, the car will tilt front and back very quickly on every bump. Car body COG will roughly move along a straight line (acceleration 1 very small) while the driver will feel every little bump because he moves up and down with the front of the car (acceleration 2 strong).
Maybe someone can help about that. I remember I asked for it one or two years ago and did not find the answer.
http://www.lfsforum.net/showthread.php?t=33581
Where does this acceleration come from?
1) Is it acceleration of the COG of the car body?
2) Is it acceleration of the car body at driver level?
Acceleration 1) is always smoother than acceleration 2) because it does not take into account car body rotations. For example when car is on tiny bumps like kerb, the car will tilt front and back very quickly on every bump. Car body COG will roughly move along a straight line (acceleration 1 very small) while the driver will feel every little bump because he moves up and down with the front of the car (acceleration 2 strong).
Last edited by Juls, .
Only driver/passenger poly count is too low for me. Helmet, hands, arms, legs are obviously square and texture can not hide it.
In recent LFS videos, using nice texture packs, the driver looks like it comes from another, older game. In game menu when the driver suit is shown the first time it may give a wrong impression about the game graphic quality.
In recent LFS videos, using nice texture packs, the driver looks like it comes from another, older game. In game menu when the driver suit is shown the first time it may give a wrong impression about the game graphic quality.
For the moment it looks like it is modeled as a simple mass/spring, as displacement is proportional to acceleration.
Damper is missing to have more realistic head displacement. After 5-6Hz, body response to vibration is lower. In ISI-based sims, there is a config file with realistic damper and spring constants for each DOF of the head.
Damper is missing to have more realistic head displacement. After 5-6Hz, body response to vibration is lower. In ISI-based sims, there is a config file with realistic damper and spring constants for each DOF of the head.
+1
Difficult to get a proper sense of speed with one regular monitor and no g-forces. It is only when you watch g-forces(F9) that you can see how painfully brutally you drive.
Two consequences for that: car seems to slip at low speed, and tyres and clutch seems to wear to easily.
I sent something few days ago. Waiting...
This smoothing may come from the tyre model, but I hope there is somewhere a filter one can disable to release the power!!
This smoothing may come from the tyre model, but I hope there is somewhere a filter one can disable to release the power!!
Last edited by Juls, .
There is jittering here for another reason. The FFB is not updated regularly, only when needed...but the filter requires 100 samples per second. So to make a quick and dirty patch I just feed the filter with the last FFB command every 100th of a second until a new command comes. There should be some smoothing there before the compression.
Because of that the filter receives aliased signal, several times the same value and then a jump to another value. The filter sees these jumps as high frequencies and amplifies them which of course is wrong.
Because of that the filter receives aliased signal, several times the same value and then a jump to another value. The filter sees these jumps as high frequencies and amplifies them which of course is wrong.
You are right initially this filter is for a different use, and it causes some side-effects... low frequencies are washed out.
It is not supposed to give a better FFB. Just a little experiment I wanted to share. In this example bumps are massively exagerated. I did not know where to put it...between misc addons and programmer forum.
For me it is amazing how alteration of FFB signal can give the feeling physics are different. Different feeling for car mass, mass transfer, bumps, suspensions feel harder...etc.Tyre model and FFB, top two priorities for a sim.
For me it is amazing how alteration of FFB signal can give the feeling physics are different. Different feeling for car mass, mass transfer, bumps, suspensions feel harder...etc.Tyre model and FFB, top two priorities for a sim.
Yes it is quite strong to make the difference more striking. I do not have time to tune the parameters, and FFB is always finally a question of personal taste.
Yes it is related to the other thread. For the motion simulator I had to develop an adaptative filter to scale down signal from sims (acceleration from -6G to 6G) while keeping or enhancing details.
And yesterday I just realized FFB is the same problem...sims have to fit steering forces (large range) into the limited range of inputs a FFB wheel supports, without clipping, without smashing details.
edit: ingame FF have to be set to 25% or lower otherwise FFB commands the dll receives are already sometimes clipped and it gives weird results like ON & OFF.
Yes it is related to the other thread. For the motion simulator I had to develop an adaptative filter to scale down signal from sims (acceleration from -6G to 6G) while keeping or enhancing details.
And yesterday I just realized FFB is the same problem...sims have to fit steering forces (large range) into the limited range of inputs a FFB wheel supports, without clipping, without smashing details.
edit: ingame FF have to be set to 25% or lower otherwise FFB commands the dll receives are already sometimes clipped and it gives weird results like ON & OFF.
Last edited by Juls, .
FFB flavour enhancer (experiment)
For people interested to try something different, this is a little experiment.
This little dll intercepts FFB commands issued by LFS, and apply some weird filter to make you feel whatever can be felt inside the FFB (bumps, grip loss...etc.) while avoiding clipping.
1) unzip this dll in LFS folder, same folder than LFS.exe
2) run LFS, and in options, set force level at 25 (default is 50)... this is needed.
3) try it on a bumpy track like South City Sprint 2. At the beginning you feel nothing it's normal it takes about 30seconds - 1 minute for the dll to adapt to force level from the car you are using. Works best with cars sliding a lot like LXs or Raceabout, I can feel earlier when it is going to slide.
To remove it, simply delete the dll file. It does not change anything in your LFS install.
This little dll intercepts FFB commands issued by LFS, and apply some weird filter to make you feel whatever can be felt inside the FFB (bumps, grip loss...etc.) while avoiding clipping.
1) unzip this dll in LFS folder, same folder than LFS.exe
2) run LFS, and in options, set force level at 25 (default is 50)... this is needed.
3) try it on a bumpy track like South City Sprint 2. At the beginning you feel nothing it's normal it takes about 30seconds - 1 minute for the dll to adapt to force level from the car you are using. Works best with cars sliding a lot like LXs or Raceabout, I can feel earlier when it is going to slide.
To remove it, simply delete the dll file. It does not change anything in your LFS install.
Last edited by Juls, .
I was not dreaming
I just recorded vertical acceleration output from GTR EVO and LFS, using F3000 on Anderstorp in GTR EVO and FO8 on south city sprint 2 in LFS.
Both tracks are bumpy, both cars are very similar, I drive like a pig...accelerations spectrum should be similar.
Very high frequency should be rare because car is not shaking on kerbs all the time. Very low frequencies should be rare because car is moving all the time. Movement should be spread over a large frequency range between low and high frequency, because car is not jumping periodically but moving very differently every second. And LFS signal should spread over a larger frequency range because LFS track is more detailed than in GTR EVO.
This is what I get from both sims (x axis is frequency from 0 to 30hz):
As you can see, GTR EVO output looks as expected....rich signal, broad of frequencies represented. And LFS output is heavily filtered. Everything above 4 Hz is smashed. This is really annoying for motion simulators. The frequency humans feel best (resonating frequency when seated) is about 5Hz.
Finally I checked with directinput capture and this does not concern FFB. Only Outsim acceleration data is filtered. From the FFT it is a first order low pass filter.
Both tracks are bumpy, both cars are very similar, I drive like a pig...accelerations spectrum should be similar.
Very high frequency should be rare because car is not shaking on kerbs all the time. Very low frequencies should be rare because car is moving all the time. Movement should be spread over a large frequency range between low and high frequency, because car is not jumping periodically but moving very differently every second. And LFS signal should spread over a larger frequency range because LFS track is more detailed than in GTR EVO.
This is what I get from both sims (x axis is frequency from 0 to 30hz):
As you can see, GTR EVO output looks as expected....rich signal, broad of frequencies represented. And LFS output is heavily filtered. Everything above 4 Hz is smashed. This is really annoying for motion simulators. The frequency humans feel best (resonating frequency when seated) is about 5Hz.
Finally I checked with directinput capture and this does not concern FFB. Only Outsim acceleration data is filtered. From the FFT it is a first order low pass filter.
Last edited by Juls, .
You mean Outsim and FFB outputs are smoothed?
If it is the case, this is a real problem. FFB wheels and motion simulators use motors which already have a tendency to smooth the output.
Instead of a smooth signal, FFB wheels and motion simulators usually need a signal which was sharpened using filters to give better sensation. So if LFS smoothes outputs like that... I can bet without this smoothing FFB would be a lot more detailed. I can see LFS tracks like South City are very detailed (there are many bumps, every single sewer plate is modeled)...this is present in the signal but very smoothed.
The only filter LFS should apply is a "brickwall" filter to cut everything above Nyquist frequency. Let's say LFS updates FFB 100 times per second, it should apply a filter which cuts everything above 50Hz (100/2) to avoid interferences inside the FFB wheel...but even that filtering is not really necessary, because these interferences only build up when FFB signal is periodical....which never happens.
If it is the case, this is a real problem. FFB wheels and motion simulators use motors which already have a tendency to smooth the output.
Instead of a smooth signal, FFB wheels and motion simulators usually need a signal which was sharpened using filters to give better sensation. So if LFS smoothes outputs like that... I can bet without this smoothing FFB would be a lot more detailed. I can see LFS tracks like South City are very detailed (there are many bumps, every single sewer plate is modeled)...this is present in the signal but very smoothed.
The only filter LFS should apply is a "brickwall" filter to cut everything above Nyquist frequency. Let's say LFS updates FFB 100 times per second, it should apply a filter which cuts everything above 50Hz (100/2) to avoid interferences inside the FFB wheel...but even that filtering is not really necessary, because these interferences only build up when FFB signal is periodical....which never happens.
Last edited by Juls, .
FGED GREDG RDFGDR GSFDG