Racer v0.8.44 released

[Ruud]

Mostly changes in the camera department.
Get it at http://www.mediafire.com/file/y1hskj807at17u9/racer0.8.44.7z
Or get v0.9.0 RC1 now at Download at http://www.mediafire.com/file/7x7v7jhof7snheq/racer090rc1.7z

Changelist v0.8.44:
- Cubemap images in shaders can be loaded from subfolders (textures/glass*.tga for example)
- Added a few Onyx functions for generic models, key pressing and car retrieval. Enough to make
animating trunk and doors (not replayable).
- Light control now works for the car in focus (even AI cars, if they don't have automatic lights turned on).
- Bugfix: light control used to work for the ghost car instead of the real car.
- Most camera position calculations moved from GPU to CPU to avoid pipeline stalls.
- Car position in 'Select Car' screen was bad.
- Onyx compiles could crash when the script had an empty last line.
- From-to (SMD) cameras now have a revised 'up' vector calculation.
- Culling in shadowmap pass reverted back to cull=none for some shadow issues.
- Color grading shader fixed; the B and G channels seemed mixed up.
- Head physics camera type added. See http://www.racer.nl/index.php?jump=tutorial/car_cameras.htm
- Improved follow of pitch/roll for fixed car cameras.
- Exhaust particle normal is listened to again.
- Ghost car now has rotating wheels.

Changelist for v0.9.0 RC1:
- Bugfix: wiper interval was too short, so it behaves the same as the 'Normal' speed.
- Bugfix: color grading was bad and could give black suns and other artifacts.
- Upon a Shift-F/Shift-R, the wheel rotation speeds were not reset.
- Add specular ambient lighting; any specular shader now gets an additional specular*lightAmbient component
to add specular light due to the sky.
- Added 'min' values for headphysics, to independently control min/max for each of the 6 degrees of freedom (by default, min=-max).
- Support for angle.xyz for head cameras, to rotate the direction of the camera.
- Fixed camera pitch/roll follow improved yet again.

 

[QuadCoreMax]

Thanks Ruud...

I wonder what is the correct shader + material settings to get a transparent fence working in mirrors + casting shadow on the ground. For now, I'm unable to merge both worlds, I get fence shadows + no transparency in mirrors or no shadows + correct transparent fence in mirrors.

EDIT :

In racer.ini, fbo_samples was set to 0.
Problem solved....back to 2.

===========================
Anyways, I see something strange with mirrors + tod & also in Carlswoods tunnel...

 

[boomer541]

Tried cameras in ver 0843 and the "0" camera had no keypad movements and the pitch,yaw,and roll angle movements with a fixed camera were way too much. They need an angle limit value. Try going up and down a bank on carlswood witn driver view camera and you'll see the roof/floor and not wher you are driving.

C-key camera has car shadows flickering like a flag in wind.

Will evaluate ver 0.0844 to see if Ruud fixed.

 

[luthobu]

I still get the UDP error with the 04X series, so I use 039 with the updated 04X structure.
Seems to work satisfactory. Other than that, it seems strange that only the shaders
on Carlswood are being updated and not the textures or the track itself. So, for my own
personal pleasure I have been "updating" it with new textures, a new X based treeline
in front of the "flat" treewall (creates depth and looks really good), and added Cruden
flags to the flagpoles (why the empty flagpoles?) Screenshot attached. If Ruud finds this
interesting, fine, if not, still fine. Just thought I would share (PS: Not finnished yet)

 

[Ruud]

@luthobu: strange that you still get that network error. There's a udpterm.exe in the install directory; can you run 'udpterm 25000'?

 

[luthobu]

@Ruud: strange indeed. udpterm reports no errors..

 

[Cosmo°]

Anybody else getting a black sun and yellow tint on the sky and in mirrors with the new utils.cg version? I switched back to the previous file for now to avoid these effects and keep auto exposure from going bananas all the time

 

[Mr Whippy]

Wow, nice work on the head cam, no compromises there it has every possibility covered :-D

Thanks Ruud!

 

[boomer541]

I looked at the cameras and for the most part they are excelent, lot of hard work on Ruud's part but...
The smd and fixed cameras have toooooo much angle movement. As I posted above just try a car with a camera located where the drivers eyes are and then drive up/down/sideways or make a sharp high speed turn and the screen image moves way, way tooooo much.
Watching a race on TV the car camera does not move up/down, etc as it would irl.

Mr. Whippy may like the bobble head cameras and the smd cams do that but the fixed cams should definately NOT!

The head cams do come close but they do move a bit and if the fixed cams were made to not move then imho the cameras would be perfect.

Hope Mr. Whippy takes another look at the cameras and does a better evaluation and Ruud makes a good and permanent fix.

 

[Mr Whippy]

Colour grading seems REALLY broken unless you use a color grade file lookup table.. and even when I'm using the default color grade LUT there are artefacts popping in and out in the sky at times, like old school palette cycling, ie, patches of feint green appearing at bright spots, then banding outwards into darker areas as new colours like feint purple appear at the bright spot.


Imo, vignetting, motion blurring, DOF, lens flares, bloom etc should all be in fs_filter files and be stackable so we can just select a bunch of effects we want or don't want and toggle them on/off.
Ie, fs_filter1=dof.cg
fs_filter2=bloom.cg
etc
etc

I've just turned it off in bloom_shadows_f.cg file
// Color grading
//color.rgb=ColorGrade(color.rgb,gradeMap);

Imo the fs_filters are getting a bit messy now, technically the current shader should be called bloom_shadows_grade_f.cg

Is there any way to have the optional type effects in fragments and then call them all in a final file called 'post_effects.cg' or something.
Then just have a list of entries like above color grading one, all in the technical right order so processing is done properly, but that can be commented on/off?

It might make more sense to do that as then we can add DOF in the list, vignetting, motion blur and so on, and then it's easier/faster to set up for photo-mode or whatever for users who are not into shader editing etc...






As for the cameras Boomer I think this is where things are confusing and I've asked Ruud about it in these latest release threads.

The camera type isn't specified, only implied by the entries in a car.ini. I'm not sure if it might be better to specify the camera you want, then define it's properties and have Racer ignore non-relevant entries... oooor, to have Racer determine the camera by the values present.


I've just spent 40mins doing a full work through from basic free, basic fixed, smd and head camera types and they all work perfectly as far as I can see.

Free, then follow locked to each and combos of pitch, yaw and roll, smd, and head cameras.
The implied system appears to work perfectly here with no confusion, you just have to be sure that you only put in the stuff Racer needs for that cam type.


Hopefully Boomer in your example it's just some issue with car.ini camera values causing an SMD to be used when you don't want it to be. Can you copy up your camera code that is causing issues, and the behaviour you expect from it?




Thanks Ruud, the head camera is exactly what I was looking for!


All seems to be good with cameras now


Dave

 

[QuadCoreMax]

Anybody else getting a black sun and yellow tint on the sky and in mirrors with the new utils.cg version? I switched back to the previous file for now to avoid these effects and keep auto exposure from going bananas all the time

Yeah exposure...
Had a strange game behavior when switching cams, flickering stuff...hmm
Still too immature/fragile this version, imo.

 

[camsinny]

Is there any way to have the optional type effects in fragments and then call them all in a final file called 'post_effects.cg' or something.
Then just have a list of entries like above color grading one, all in the technical right order so processing is done properly, but that can be commented on/off?

It might make more sense to do that as then we can add DOF in the list, vignetting, motion blur and so on, and then it's easier/faster to set up for photo-mode or whatever for users who are not into shader editing etc...

Dave, you can do stuff like this. Have a look at the HDR tonemapping techniques. There's about 12 or so techniques listed in one file (these could easily be split out to a different file for each and just have an #include at the top of the file) with a function at the end of the file just calling up one of previous functions.

I'm not sure it's the most efficient way, it is however possible.
I'm certainly not putting my hand up to split all the functions up into separate files though haha.

 

[Alex Forbin]

I looked at the cameras and for the most part they are excelent, lot of hard work on Ruud's part but...
The smd and fixed cameras have toooooo much angle movement. As I posted above just try a car with a camera located where the drivers eyes are and then drive up/down/sideways or make a sharp high speed turn and the screen image moves way, way tooooo much.
Watching a race on TV the car camera does not move up/down, etc as it would irl.

Mr. Whippy may like the bobble head cameras and the smd cams do that but the fixed cams should definately NOT!

The head cams do come close but they do move a bit and if the fixed cams were made to not move then imho the cameras would be perfect.

Hope Mr. Whippy takes another look at the cameras and does a better evaluation and Ruud makes a good and permanent fix.

Boomer,
All you need to do to turn off the head tilting is to change the distance variable to 0 for roll/tilt/yaw. The new camera system looks very flexible, look at the example
Ferr. 312 Ruud posted for the last release.

Alex Forbin

 

[Stereo]

Whoops, one of the lines I changed in the colorgrade function causes problems on tracks without a colorgrade map defined.

  half3 scale =(lutSize-2.0)/lutSize;

Is what it should be.

 

[boomer541]

Yes, Mr Whippy, the head camera works very well with the keypad numbers all working, camera rotaes round the camera location and the car moving properly with pitch,roll and yaw of car.
My issue is with the smd and fixed cameras:
SMD and FIXED - pitch,roll and yaw of car produces too much movement of the screen view. I see the car roof/floor or looking out the window. this with fixed camera pitch,rool,yaw all = 1.
With fixed camera pitch, roll, yaw =0 the car is undriveable as the view rotates with the car direction.
I'll post my fixed camear setting that doesn't work properly and you can try it. I followed the info on racer nl.

camera9
{
name=inside driver
follow
{
pitch=1
yaw=1
roll=1
}
offset
{
x=-0.275000
y=-0.800
z=0.280
}
angle
{
x=-6.0
y=-176.000
z=-1.736111
}
; Type of model to use; 0=outside, 1=inside, 2=none
model=0
wheels=1
fov=62
}

Alex, I'll try your tip to change the distance variable which only applies to SMD cameras.

 

[Mr Whippy]

Hmmm, weird Boomer.

The pitch follow lock isn't working.

I've just gone through with a working fixed camera and the value that breaks it was the angle.y value.

I'm using an angle of 180deg there to spin the camera around, rather than -180deg


It's hard to test on my current test car because it doesn't roll much but I wonder if negative values break things there generally and the follow locks start to fail... hmmm...

Perhaps try use 360 + your current negative offset to get the angle in positive form back to the same location?

Ie:
354
184
358.27

Hmmmm... certainly another little bug that is gonna catch people out!

PS, pretty sure angle values don't work with SMD still? Ie, the entry tree in car.ini for angle should be ignored for SMD so remove the entries as that may cause errors if present in some odd Racery way

Dave

 

[Ruud]

Whoops, one of the lines I changed in the colorgrade function causes problems on tracks without a colorgrade map defined.

  half3 scale =(lutSize-2.0)/lutSize;

Is what it should be.

Not quite it seems; the wrapping of the texture was still at repeat, hence the strange clustersize. If you do 'return color' at the start, you'll notice a brightness change. I've modified the texture parameters to clamp_to_edge and that seems to work better. I'll post the fixes later.

 

[Ruud]

I've uploaded a fix for the colorgrading at http://www.mediafire.com/file/xi1xqcs45ucfc16/rr0845.7z
Put utils.cg in data/renderer/common, and racer.exe/pdb in the main directory.

 

[Ruud]

Hmmm, weird Boomer.

The pitch follow lock isn't working.
PS, pretty sure angle values don't work with SMD still? Ie, the entry tree in car.ini for angle should be ignored for SMD so remove the entries as that may cause errors if present in some odd Racery way

Dave

Hm, the pitch/roll angles used degrees, then sin() was called as if they were radians. That it ever worked. ;-) It seems better now.

For SMD, the angles don't work, no. That is mainly because the SMD does a lookat from src to dst, so any extra angles can be done by moving the dst point instead.

I've added a 'min' value for the 6 degrees of freedom of the head camera, and added angle.xyz support for it as well for the next version.

 

[Ruud]

There's a new version, v0.9.0 RC1 (to step aside from the path of ever-continuing 0.8's).
Download at http://www.mediafire.com/file/7x7v7jhof7snheq/racer090rc1.7z

It has Mr Whippy's specular ambient lighting added; quite subtle fortunately. ;-)