Racer v0.8.38 released

Ruud · Jan 10, 2012

Racer v0.8.38 is now available at http://www.mediafire.com/file/a9z1omd6rmhzymb/racer0.8.38b.7z

Enjoy!
Ruud

Changelist:
- Look_up/look_down controls added for to make TrackIR devices possible.
That makes head tracking possible, although currently a bit crude.
- In your controller file you can add global.up_down_velocity to set up/down look velocity (default=250)
- In your controller file you can add global.up_down_look_max to set the max up/down look angle (default=45)
- Removed energy conserving diffuse/specular lighting for version 0.9.
- Auto exposure turned back on. It can cause dips in framerate on some systems (every second, a grab is mipmapped to obtain the scene brightness).
- Added shader .mipmap_bias for the global shader and optionally for separate layers.
- Added cubemap mipmapping to all reflection shaders for environment mapping.
Requires a good graphics card; otherwise, turn off envmap.generate_mipmaps (set to 0).
- Fixed keep_aspect (dials/views.ini) for multi-monitor setups.
- Setting up graphics settings and starting a race would crash.
- Added dev.collisions setting to globally turn off collision checking.
- Wireframe mode gave bad texturing for the rest of the graphics.
- Trackcam FOV clamped to zoom range indicated by the camera
- Newton solver parameters reverted in the hopes of fixing now & then hangups (10-200 seconds each, after several hours of play)
- Car camera offset seems back working; the FIXED camera type should now work correctly again.
- Shadowmapping in car camera mode focuses on the car, even if the camera from/to positions are some distance away from the car.
- Reverted back to FMod 4.30 (was v4.36) since some people had volume problems at startup.
- Differential power_ratio warnings were mistakenly given for non-LSD type diffs.

Alex Forbin · Apr 21, 2012

Mr Whippy said:
I want SMD but also with angle and offset, then we can do some clever things with them...

Instead SMD just do some things better but some things worse, meaning they are not really a replacement for the old cameras, just something different... much like the two types of track cameras

Dave

I used to use SMD cameras exclusively, but their constant jumping in turns on large tracks and goofy offset-rotation has pretty much made them useless to me now. I currently use boring fixed cameras.

Alex Forbin

boomer541 · Apr 21, 2012

Cosmo, It's up to the car creator as to having car camera change position on different tracks. It may not always be desired. I just pointed out what the cause is.

I agree with Mr. Whippy! But I don't call them SMD cameras as Ruud calls them the free car camera, whatever suits! With the "SMD" cameras maxdist set = 0 there is no jumping around and there is NO car rotation for cars with cg xyz not = 0.

But there are problems that perhaps Ruud can fix and should fix. The keypad keys should function the same as fixed cameras and angle adjustment is definately needed!

If the car mesh is moved to make the nullpoint 0,0,0 where the cg is in racer then all the stuff in car.ini will need to be changed. What a horrible thought. That's why I'll use the "SMD" camera for driver views. It works!

Enough on cameras, back to working on updating cars.

Mr Whippy · Apr 22, 2012

Updating cars, that is all we seem to do hehe...

One for the wish list, set a camera in Racer, then have a 'button' that saves it to car.ini...

CarLab used to do all this stuff but that hasn't worked for probably 8 years now haha. Bring back CarLab

Dave

Alex Forbin · Apr 22, 2012

Ruud says the problem is due to single-precision math. Another solution I've read about is to move the world instead of moving the car.
see here... http://answers.unity3d.com/questions/54739/any-solution-for-extreamly-large-gameworlds-single.html
Alex Forbin

Mr Whippy · Apr 22, 2012

I don't get it really.

Surely you can just offset from the car or something? The car doesn't jerk around as you hit bumps on corners miles away from the world 0,0,0, so why can't we just put the camera doing it's SMD thing at the centre of the car coords which are smooth and then offset it!?
Ie, the car has SMD in the form of it's suspension and that works well enough. Why does the camera maths have to jerk?

Dave

Some1 · Apr 22, 2012

Mr Whippy said:
I don't get it really.

Surely you can just offset from the car or something? The car doesn't jerk around as you hit bumps on corners miles away from the world 0,0,0, so why can't we just put the camera doing it's SMD thing at the centre of the car coords which are smooth and then offset it!?
Ie, the car has SMD in the form of it's suspension and that works well enough. Why does the camera maths have to jerk?

Dave

Actually, it is not the camera maths. Take a very big track (a simple big plane should do it), select a non-SMD car camera and drive far away from the track's nullpoint. Then observe as the car seems to jerk around just a little bit. With SMD camera, the jerking is more abvious though...

The floating point inaccuracy issue in Racer is very old and has been discussed years ago, and Ruud once said that it is almost impossible to fix at this stage. Consider that the Racer codebase is huge and although the fix could be easy in theory, it could be very hard to implement the fix in all over the codebase.

I guess we just have to accept the bug and not make too big tracks...

Ian Strom · Apr 22, 2012

I think this really only affects us unless someone licenses the Racer engine for a driving school simulator setup.
I doubt anyone else using it for actual racing would generally notice this issue given the size of most tracks.

But I do have to say that it would have been nice to see the effort made to fix it back then before Racer got even bigger. It is only going to get bigger in the future, of course..

Unless Ruud mothballs Racer and goes to start work on a new engine from the ground up as a separate product!

boomer541 · Apr 23, 2012

Car cameras became a problem adter ver. 0.0834 when Ruud made the move_cg variable for racer.ini which was due to a problem with cars rotating round the nullpoint and not the cg point. All could be solved if cars are made with the nullpoint at the cg point and have cg = 0,0,0, but that is not the way cars are being made. Most cars are made with the nullpoint at the center of the car and the cg is then offset to adjust the handling.

I don't understand why Ruud can't make the car camera rotate round the nullpoint and the car rotate round the cg which would solve the problem, imho.

Enough about cameras, what other problems can we come up with?

Stereo · Apr 24, 2012

Code:

get (pbody) rot
  returns float[4]

This script function does something strange.
x,z = cos(angle/2),sin(angle/2)
When the object's pointing due x, it returns (1,0) for x,z - when it's pointing due y, it returns (sqrt(2)/2, sqrt(2)/2).
The actual range ends up being that the car can point -120 through to +240 degrees (using x,z)
Which corresponds to rot = cos(-60) to cos(120), sin(-60) to sin(120) degrees.

I was testing with a car which is harder to intentionally rotate along the other two axes so I'm not really sure what y and w do. When the car's pointing +x, y varies as the nose lifts/falls and w as it rolls. When the car's pointing -x, w varies as the nose lifts/falls and y is varying with rolls. At +z, both y and w vary with either one.

I'm really not sure what this function's outputting, which makes it hard to use the numbers in scripts and get expected results.

Code:

atan2 (float[2])
  returns float

This script function actually requires a float[39], and operates on the 38th and 39th entries in the array.

It also stops working after a couple seconds and crashes the script.

Code:

float $rot[4]
float $atan
string $out
while 1 {
$rot = get $car rot
$atan = atan $rot[0]/$rot[2]
$out = "Current angle: "
$out = $out + $atan
paint $out at float[2]{10,10}
interrupt
}

This returns from -pi/2 to +pi/2, which is at least usable (double it to get the actual angle). It's just atan2 and rot that are confusing on their own.

Alex Forbin · Apr 24, 2012

Mr Whippy said:
I don't get it really.

Surely you can just offset from the car or something? The car doesn't jerk around as you hit bumps on corners miles away from the world 0,0,0, so why can't we just put the camera doing it's SMD thing at the centre of the car coords which are smooth and then offset it!?
Ie, the car has SMD in the form of it's suspension and that works well enough. Why does the camera maths have to jerk?

Dave

Yeah, I don't know myself. I'm sure that code that's over 10 years old must really be a pain to update. It may be the reason updates have gotten slower and slower over the last few years.

I've noticed that there are some amazing advances in sims that are in development right now. Project C.A.R.S., rFactor2, Assetto Corsa.
A couple are said to be mod friendly too.

Alex Forbin

Some1 · Apr 24, 2012

Stereo said:
Code:

get (pbody) rot returns float[4]

This script function does something strange.
x,z = cos(angle/2),sin(angle/2)
When the object's pointing due x, it returns (1,0) for x,z - when it's pointing due y, it returns (sqrt(2)/2, sqrt(2)/2).
The actual range ends up being that the car can point -120 through to +240 degrees (using x,z)
Which corresponds to rot = cos(-60) to cos(120), sin(-60) to sin(120) degrees.

I was testing with a car which is harder to intentionally rotate along the other two axes so I'm not really sure what y and w do. When the car's pointing +x, y varies as the nose lifts/falls and w as it rolls. When the car's pointing -x, w varies as the nose lifts/falls and y is varying with rolls. At +z, both y and w vary with either one.

I'm really not sure what this function's outputting, which makes it hard to use the numbers in scripts and get expected results.

I'm not sure either, but since it's a float4 and rotation, I'd guess it is a quaternion?
http://content.gpwiki.org/index.php/OpenGL:Tutorials:Using_Quaternions_to_represent_rotation

Stereo · Apr 24, 2012

Seems plausible... I had slight axis confusion, -z is (0,0,1,0), +x is (sqrt(2)/2, 0, sqrt(2)/2, 0), +z is (1,0,0,0)

Assuming that this is w,x,y,z as in that documentation, then the +z axis is the 'no rotation' option. x is rotation around the x axis, y is rotation around the y axis, and z is rotation around the z axis. Which makes sense...

This is slightly complicated in that the documentation lists them in (w,x,y,z) order but goes on to do all the math with them in (x,y,z,w) order - presumably cause OpenGL's float4.x is the first element, etc. Anyway, Racer's returning them in (w,x,y,z) order.

If I may make a suggestion, a scripting function that transforms world coordinates to screen coordinates would be nice (could use it to paint AI1, AI2 etc. above cars, and so forth - or more useful, like painting wheel debug info over the wheels it's affecting)
Probably would be

Code:

get screenpos of (float[3])
Returns:
float[3] 
Comment:
x,y offset in the display, and depth from the screen.  paint (string) at screenpos.xy for example

QuadCoreMax · Apr 26, 2012

+ 1 Stereo

& thx Alex, didn't knew for Project CARS, which seems a great one, still that obligatory online stuff, I really don't appreciate that much...sometimes, you just want play with your smart AI & custom scripts...

Alex Forbin · Apr 26, 2012

QuadCoreMax said:
+ 1 Stereo

& thx Alex, didn't knew for Project CARS, which seems a great one, still that obligatory online stuff, I really don't appreciate that much...sometimes, you just want play with your smart AI & custom scripts...

I feel the same way, RF2 allows offline against AI, I believe Assetto Corsa does as well.

Alex Forbin