Racer v0.8.44 released

Ruud · Jun 22, 2012

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.

Some1 · Jun 25, 2012

Ruud said:
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. ;-)

I tested it, and I'm pretty happy with this version. As for the cameras, only thing that bothers me a little is that now the numpad keys are mirrored, when rotating around the car.

Mr Whippy · Jun 25, 2012

Just curious Ruud, what is the min value for the head camera?

Ability to pre-load so movement doesn't begin until certain force levels are met?

Numpad flip will be something I can get used to but if it's an easy fix, then fix it I guess hehe.

The specular stuff is nice to see in there too Ruud, thanks for that. It makes sense in theory and in practice so hopefully as people play with their tracks it'll generally be a positive thing for realism and not be something they feel they are fighting against

As per V0.9, is this just moving on from V0.8x versions since it's fairly well clearly developed now vs those versions?

I'm looking forward hopefully to V0.9.x being physics iterations to try iron out long-standing problems and improve things... perhaps also finally finishing up the sound system (ie, on/off throttle noises etc)
Onyx and ability to edit car.ini variables on the fly will maybe allow us some great abilities too. I really want to adjust pacejka in real-time via Onyx to get a better limit transition tyre behaviour for instance.

Great work as always Ruud, I look forward to the next few years of where Racer can go. I just really want to get some content finished too haha... so I have plenty to get on with!

Dave

Ruud · Jun 25, 2012

Some1 said:
I tested it, and I'm pretty happy with this version. As for the cameras, only thing that bothers me a little is that now the numpad keys are mirrored, when rotating around the car.

The idea was to keep all cameras doing the same thing. For head cams it seems pressing keypad-4 (left) to move the head left is good to replicate for other cameras with the same orientation (watching forward to the nose of the car).

luthobu · Jun 25, 2012

Still have the strange UDP error with 09rc1. For some reason it still thinks
I am running Racer twice. I'll debug it and see if I can find a solution..

luthobu · Jun 25, 2012

@Ruud: There is a surprise for you in your email

Ruud · Jun 25, 2012

Mr Whippy said:
Just curious Ruud, what is the min value for the head camera?

Ability to pre-load so movement doesn't begin until certain force levels are met?

Numpad flip will be something I can get used to but if it's an easy fix, then fix it I guess hehe.

The specular stuff is nice to see in there too Ruud, thanks for that. It makes sense in theory and in practice so hopefully as people play with their tracks it'll generally be a positive thing for realism and not be something they feel they are fighting against

As per V0.9, is this just moving on from V0.8x versions since it's fairly well clearly developed now vs those versions?

I'm looking forward hopefully to V0.9.x being physics iterations to try iron out long-standing problems and improve things... perhaps also finally finishing up the sound system (ie, on/off throttle noises etc)
Onyx and ability to edit car.ini variables on the fly will maybe allow us some great abilities too. I really want to adjust pacejka in real-time via Onyx to get a better limit transition tyre behaviour for instance.

Great work as always Ruud, I look forward to the next few years of where Racer can go. I just really want to get some content finished too haha... so I have plenty to get on with!

Dave

The camera min value is exactly that, although I see it still has to be implemented in the integration step. ;-) For example, for pitch, to use min=0 and max=10 means it will never pitch backwards, only forwards.

v0.9 RC1 is just v0.8.45 if you will, there's no sudden jump. It's just converging to simple bugfixes only. Psychologically nice to seem to get there. ;-) And all that content out there that is waiting for a new steady point...

Onyx is really a big design thing that isn't really meant for v0.9, but a few useful functions can go a long way, also for live Pacejka tweaks probably. I posted a Carlswood update a few weeks ago where you could see a bit where it might be heading; entities controlled by scripts (in the future, a car probably is also an entity).

Mr Whippy · Jun 25, 2012

The head camera is really good. Finding good values is just a matter of trail and error but I really like the sensations I get now, it feels like I'm really in sustained high g corners now when my actual real head is leaning to level out the subtle angle in the horizon on-screen!

Also they seem more robust at large distances from the world origin, on my 8km road course at the far end the result is still noticeably less smooth, but probably 4x less so than with the full SMD system... it's certainly now smooth enough to be considered ok for V0.9 on bigger tracks!

Dave

boomer541 · Jun 26, 2012

Thanks Mr. Whippy for looking at my camera problem. I'll try your info and see what happens.

QuadCoreMax · Jun 26, 2012

The fast_time command doesn't pause when paused...

boomer541 · Jun 27, 2012

Just made angle y a positive angle and the fixed cameras worked as they should in ver 0845. Thanks Mr Whippy for the tip that fixed my cameras.
Head camera was looking in wrong direction when going erom ver 0845 to ver 090 and adding angle x,y,z with proper angles worked really well.
I haven't figured out how to use the min value in the head camera.
Ruud The cameras are working very well now so please don't fix them.

camsinny · Jun 27, 2012

boomer541 said:
Ruud The cameras are working very well now so please don't fix them.

Hahahaha

Ruud · Jun 27, 2012

boomer541 said:
Just made angle y a positive angle and the fixed cameras worked as they should in ver 0845. Thanks Mr Whippy for the tip that fixed my cameras.
Head camera was looking in wrong direction when going erom ver 0845 to ver 090 and adding angle x,y,z with proper angles worked really well.
I haven't figured out how to use the min value in the head camera.
Ruud The cameras are working very well now so please don't fix them.

Unfortunately I did have to revert the SMD camera up method. It always pointed up, which meant as the car rolls, it will roll the car and not let the entire view roll. This was unusable for our simulators (where we use SMD cameras that are tied to the car, even if it rolls). The SMD 'up' generation will probably always have some kind of gimbal lock though...

boomer541 · Jun 28, 2012

Thanks Ruud, I never notived that.

Mr Whippy · Jun 28, 2012

Ruud, just a quick query regarding splines.

Is this the correct requirements for good splines?

lines
{
count=339 ;the number of cross-sections, the start/finish being the first AND last cross-section

paint_start=0 ;obviously the cross-sections are counted from and including 0 > 338, a total of 339 cross-sections

paint_end=339 ;a bit of an anomaly? shouldn't paint end be 338? Does 339 even exist to reference?

use_mesh_hits=0 ;whether to drive on the mesh or splines

}

I'm mainly struggling because Racer spine management via trackEd is a real pain if you want to go changing splines. A rebuild is actually quicker each time vs editing the existing ones.
However, it's never specifically noted anywhere how to end your splines.

Do we put line0 at the start/finish line, and the last line (lineZ) at the start/finish line too?

Should paint_end be the last line number (ie, paint_end = lineZ), or should it be lineZ+1 as it is in Carlswood (pointing to a non-existent line?)

I've been trying to train some AI using CTRL6 + AI on. It works pretty nicely on Carlswood but I'm having issues getting my new splines on another track to even work. The AI just ignores them so I'm wondering if it's a bug or bad splines or what?!

Also, the AI learning could be improved. If the car leaves the track and returns back on it's own it skips some cross-sections and so stops learning. Maybe you can have AI mode automatically do a 'CTRL F' reset if it leaves the track so it can continue learning?

When you do a CTRL F reset the problem then is the car sets off from stopped and so it instantly says 'faster' in the readout. Would it be sensible to have any situation where a reset was needed reset the preceding values speeds to the last lap? I seem to be in a situation where as soon as a car starts going off on a bend (needing a reset) it will perpetually go off there faster and faster each time. It's like it's learning that it needs to go faster because of the reset and starting from zero speed.

Not a hugely important fix on the AI learning, but I'd really like some clarification on the splines. I'm looking to make a Max > spline script so understanding exactly what splines/spline entries *should* be like is important

Thanks

Dave

Mr Whippy · Jun 29, 2012

Also another issue I still have here, and pretty sure it's shader related.

Shader entries:

Code:

vf_bump
{
    vertex_shader
    {
        file=standard_bump_v.cg
    }
    fragment_shader
    {
        file=standard_bump_f.cg
    }
}

Code:

shader_wall~vf_bump
{
    specular=0 0 0 0
    shininess=6
    cast_shadow=1
    tangents=1
    layer0
    {
        map=texture\wall_01.tga
        depthwrite=1
        alpha_to_coverage=1
        alphafunc=gequal 128
        wrap_t=clamp_to_edge
    }
    layer1
    {
        compression=0
        mode=linear
        map=texture\wall_nrm_01.tga
        wrap_t=clamp_to_edge
    }
}

The textures are:

tex0
rgb = diffuse
alpha = transparency

tex1
rgb = normals
alpha = specular

The wall casts shadows in both directions ok.

The wall transparent cut out works ok from the forward facing direction.

It disappears on it's opposite side which is fine (not two sided)

The problem is that when it is lit from the back it lights up as if lit from the front, and that also means shadows that are cast onto the back of it are visible from the side you are looking at it from.
It's like it's lighting is two-sided (or it's normals are) or something.

I can post pics/resources if anyone needs them, but pretty sure they are fine. I've had this problem a few years but pretty sure it's shader/normal management related and not resource related...
Unless it's to do with one of those numerous settings like cull or depthwrite or something but I'm fairly sure they are correct too!

Thanks

Dave

Mr Whippy · Jun 29, 2012

Sorry for the spamming Ruud,

Just another note on the AI learning mode.

I think the issue is that the car accelerates through braking zones and keeps thinking it's ok, and then when suddenly it deviates from the desired racing line it thinks 'slow down' so it remembers next time to slow down at the corner turn in point where it ran wide last time.

Obviously since the run through the braking zone had ample grip last time, it runs FASTER into the braking zone the next time, meaning even more spinning off ensues etc etc...

The AI learning really does seem really cool.

I'm training AI (or recording my own laps) with rain = 0.1 to get ~ 90% grip, then when racing against it I set grip to 1.05 in the AI section, so the AI learns or records with less grip then races with a bit more (makes it nice and stable it seems)

Just this braking zone stuff it really struggles with.

Perhaps look at the over-speed value at the current spline and remove it from the spline before the one where it over-sped as well. That way it will soon cascade back down the braking zone until over-speeding at the corner isn't evident any more.

I think

Dave

Ruud · Jul 2, 2012

Mr Whippy said:
Ruud, just a quick query regarding splines.

Is this the correct requirements for good splines?

lines
{
count=339 ;the number of cross-sections, the start/finish being the first AND last cross-section

paint_start=0 ;obviously the cross-sections are counted from and including 0 > 338, a total of 339 cross-sections
paint_end=339 ;a bit of an anomaly? shouldn't paint end be 338? Does 339 even exist to reference?

use_mesh_hits=0 ;whether to drive on the mesh or splines

}

paint_end should be 338 indeed. That's also the default value if you don't define it.
I've modified minimap painting a bit so that painting is like:

Code:

for(i=paint_start;i<=paint_end;i++)

Whereas it was:

Code:

for(i=paint_start;i<paint_end;i++)

so that you don't miss the last spline being painted (giving a straight line).

On the AI, that doesn't really work well indeed, mainly when the car gets a bit further into the higher velocities. I don't plan to fix that for v0.9 yet...

Ruud · Jul 2, 2012

Mr Whippy said:
Also another issue I still have here, and pretty sure it's shader related.

Shader entries:

Code:

vf_bump { vertex_shader { file=standard_bump_v.cg } fragment_shader { file=standard_bump_f.cg } }

Code:

shader_wall~vf_bump { specular=0 0 0 0 shininess=6 cast_shadow=1 tangents=1 layer0 { map=texture\wall_01.tga depthwrite=1 alpha_to_coverage=1 alphafunc=gequal 128 wrap_t=clamp_to_edge } layer1 { compression=0 mode=linear map=texture\wall_nrm_01.tga wrap_t=clamp_to_edge } }

The textures are:

tex0
rgb = diffuse
alpha = transparency

tex1
rgb = normals
alpha = specular

The wall casts shadows in both directions ok.

The wall transparent cut out works ok from the forward facing direction.

It disappears on it's opposite side which is fine (not two sided)

The problem is that when it is lit from the back it lights up as if lit from the front, and that also means shadows that are cast onto the back of it are visible from the side you are looking at it from.
It's like it's lighting is two-sided (or it's normals are) or something.

I tried that on a Zandvoort wall here, but that seems fine. Do you indeed have images, or better, a binary (part of) the track?

Mr Whippy · Jul 2, 2012

If it's fine at your end on that wall issue, then it's very likely something at my end. I'll do some more testing here and if I still have trouble I'll send it over.

As per the splines, should splines start AND end on the start/finish line?

ie, line0 and lineLast share the same co-ordinate entries on a looping track?

So if I draw a ribbon in 3DS Max and split it at the start/finish line, and use the coords of the verts for the spline entries, then the first and last pairs of verts coincide at the start/finish line...

I'm just looking to make a few basic 3DS Max scripts and little tutorials that are basic but very clear so there is no confusion.

The "paint" terms for example are technically incorrect in Carlswood.
Should the mini-map show a little gap or not, or does it not matter what the paint values are, are they literally just used for the mini-map?
The little gap looks quite nice to show where the start/finish line is that is all

Thanks

Dave

Ruud · Jul 2, 2012

Mr Whippy said:
As per the splines, should splines start AND end on the start/finish line?

ie, line0 and lineLast share the same co-ordinate entries on a looping track?

The "paint" terms for example are technically incorrect in Carlswood.
Should the mini-map show a little gap or not, or does it not matter what the paint values are, are they literally just used for the mini-map?
The little gap looks quite nice to show where the start/finish line is that is all

Yes, the splines first and last lines should be an exact match in spline.ini. The reasoning behind it is that the spline is really a collection of triangles, not lines really. And for a spline with lines.count=400, the last triangles are defined between line398 and line399. If line399 is not the startline again, this would mean there are no triangles in the last part of the track (just before the startline), creating a small gap.

I've fixed Carlswood's spline.ini indeed.

The minimap should not show that gap. I've noticed that too, being a nice point for the S/F line (or timelines perhaps). But on Zandvoort, this gap was larger (20m) and showed as an actual gap of a couple of pixels, instead of a line. I wouldn't abuse this 'feature', since the car not being on the spline means AI and position updates are not working there.

The timeline is currently independently defined from the spline, but perhaps extra drawing of the timelines in the minimap might be nice.

BTW motion blur here is getting much better; got rid of a bit of the echoing effect, the car is now also blurring if moving. Does require motion_blur for rotating objects (the wheels).