Racer v0.8.28 released!

[Ruud]

Since X-mas is still so far off. ;-)

Get it at http://www.racer.nl/download/racer0.8.28.zip (83Mb)

This one does seem close to v0.9, except perhaps for some replay enhancements.

Changes (some already posted in the v0.8.27 thread):
- Minimap was painted even if no splines were present
- SMD chase cam shadow focus is now on the car, not near the camera itself
- 3rd shadow split distance reduced to 500m for detail. Last split is now faded out.
- Large car CG offset could get some 3D objects culled incorrectly.
- 'Select car' screen gave car.ini errors which were incorrect (due to fast loading of only the first part of car.ini)
- Force feedback was passed to steering wheel even if steering was not done through that wheel
- resolution.render_aspect didn't work; fixed
- Shadowmapping tweaked again for even less Z correction
- Pacejka Player tweaking lambda values wasn't correct for MF5.2 curves
- Backfire 'likeliness' removed until we get better turbo behavior (>v0.9)
- 'grip 0.5' appeared to also reduce engine torque. Fixed (doubly stored data in the code, as if grip=1).
- Only the first 2 splits are blurred
- Autoclutch RPM now slams the clutch harder around the optimal RPM. Works to get at the optimal torque rpm
when driving off, although it is a bit harsh. Seems ok when I look at g-force graphs though.

 

[luthobu]

Heh. It's not finished until it looks like this: the realism, the shaders, the physics! Perfection

 

[aadilf1]

I need the FF fixed before the end PlZ!

 

[KS95]

Oh jeez. A fix has been posted..

It's not great, but it works.

 

[FiftyOrange]

Heh. It's not finished until it looks like this: the realism, the shaders, the physics! Perfection

**** that's even got a fuel meter, which makes it way more advanced than Racer.

 

[krsman3d]

**** that's even got a fuel meter, which makes it way more advanced than Racer.

Actually, Racer has got a fuel meter too. And it has been there for quite a while.

 

[luthobu]

Actually, Racer has got a fuel meter too. And it has been there for quite a while.

Correction, Racer has a fuel meter /option/ - I don't know of any cars that use it though.
If I press the right key combo I can see how much fuel I have used, but a fuel bar or meter
I have not seen implemented yet. There is however some documentation on how to do this
on Ruuds site. Would be nice to have one on-screen like the gauges.

 

[slyda]

Season greetings to everyone overhere,

I have a request for Ruud,could you please link the rainspray to offroadmaterial [sand,gravel] to get some nice dustcloud when driving offroad and stops when you roll on the tarmac?
if i raise the life and growth graveldust paricles the framerates dropping realy bad! after experimenting with coloring the rainspray and driving
offroad i got a nice dustcloud without framerates dropping

 

[Ruud]

Not sure if this is also evident with ctrl F, it's not a problem with ctrl P, but it is with ctrl R. Ctrl F would be a viable solution but as yet I'm pretty much 99% sure use_mesh_hits still doesn't work meaning I'm not running splines on many tracks as it just ruins them (I'll have to make a track specifically to prove this but it is frustrating having to do this to prove the case)

If I modify Carlswood's spline.ini to contain:

lines
{
count=339
paint_start=0
paint_end=339
use_mesh_hits=1
}

I can see from the car motion that its using the mesh instead of the spline. Sure, the debug screens will indicate 'on spline' but that's true and used for AI etc, but the intersection point of the wheels is taken from the mesh. I just tried this and it works.

As for the clutch, I'll post a v0.8.29 which modifies clutch a bit. Several systems tried to overrule clutch amount, each taking care of the other subsystems. Too many systems trying to check eachother; now it all boils down to 1 central point where all the desired clutch values (shifting autoclutch, anti-stall, driver controls) are compared and the highest clutch value is used (the one who depressed the pedal most wins). I've also tried v0.8.29 with brake+throttle which seems to work (low-speed adjustments only).

 

[Ruud]

I need the FF fixed before the end PlZ!

In your controls ini file, add time_per_output=100 (search this thread for 'time_per_output'). That slows down things. Or set forcefeedback to 0 to skip forces. The driver for those slow FF wheels just busy wait for each poll, which is quite ridiculous these days. I won't add threading of the wheel polling since all current wheels do it right, and the chance of breaking things in the process is actually quite high.

 

[Ruud]

Get v0.8.29a from http://www.racer.nl/download/racer0.8.29a.zip (just the exe). Changelist for that:
- Added surface 'forbidden' field (in special.ini); if set to 1 (default=0) it will reset your
car to the road if you set racer.ini's assist.time_allowed_offroad. See http://www.racer.nl/reference/tracks_surfaces.htm
- Car and track version checking is now updated to '090'. If your track/car doesn't match this
compatibility info, you'll get a warning in QLOG. All content must be updated!
- Autoclutch RPM now only really hunts for max torque in 1st gear. Other gears are the old way (more subtle).
- 'Ini' tool can now modify references ('ini wheel0.pacejka pacejka_front' for example).
- Clutch mechanism revised since some clutch-controlling subsystems (gearbox/anti-stall/controls)
would not mix correctly, giving hard jerks when shifting up/down.
- Added dbg_car.max_brake_reduction (=0.2) which determines the minimum brake torque reduction when wheels stop spinning.
- Added car.ini engine.launch_control to specify autoclutch_rpm=0 behavior in 1st gear.
- Added X-tree shaders for nicer X-tree shading, see http://www.racer.nl/tutorial/xtrees.htm
- Cg parameters Kd, Ka, Ke and Ks (diffuse/ambient/emission/specular) expanded to pass RGBA instead of just RGB.
Not used in the Cg shaders yet though; the use is a bit unclear still.
- Minimap painting was bad when car select screen was called first. Same for mirrors.
- Minimap paint could cause statistics paint to become transparent
- Added 'graph step 0 1 clutch' option to visualize clutch behavior.
- Wheel heat shader gives more light

 

[Mr Whippy]

Hi Ruud, sounds like a great update, thanks.

I'll re-visit splines again with a test track that should emphasise it working or not (saw-tooth polygons with smooth splines underneath)... should be obvious then if it's working or not

Just as a quick query, is there anything else I should be doing with the splines to make them not be driven on? Ie, do they have to be a loop, or anything else like that?



The tree shader is interesting, but as you may have guessed, it now leaves (hehe) me with lots of questions relating to best practice.
Ie, cull=none seems effective in saving polygons, and automatically flips the texture so if a tree is non-symmetric in it's texture, it appears with the correct appearance from both front or back. So a big overhang to the right hand side from the front, is overhanging the same way when you get to the other side.
It would appear with this new technique and not being allowed to flip the u=0..1 left to right tex coords, that a non-symmetric tree texture will look the same from both front and back (which is wrong)
Right away that is a big downside forcing the texture coords to always flow one way.

Is there no elegant way to have the front/back detected and thus detect the triangles normal and just flip it if it is the back side? Obviously then speed is an issue but it does seem to make sense to do it that way.

Or is the standard_xtree_basic_f.cg that above? Or does this "basic" shader look less visually nice than the round normals version?

Just seems we have limited ourselves again by not allowing any texture flipping to get the nicest looking trees. The best looking or most memorable trees are often those with character and asymmetry, but now they will look inaccurate from one direction, or be hampered with the less nice shader technique?!

Hmmmmm

PS, are the shaders available anywhere to try?


Thanks

Dave

 

[Mr Whippy]

Quick check on the use_mesh_hits

I'll build a spline test track that keeps things really tidy and I can post up here... maybe add it to Some1's shadow test track


I've even edited the Carlswood spline.ini file as you have, and then added 10cm to the first 11 spline entries Y coords, and you can clearly see the car drive 'up' on to these splines at the start finish line, and then back off them further down before the 1st bend.


Can you do the same Ruud? See if it works at your end or not?

lines
{
count=339
paint_start=0
paint_end=339
use_mesh_hits=1
}
line0
{
cp0=-87.821060 2.605890 -280.368469
cp1=-100.116852 2.606030 -280.212341
elevation=0.000000
flags=0
}
line1
{
cp0=-87.674240 2.565230 -270.128632
cp1=-99.970352 2.565450 -269.993896
elevation=0.000000
flags=0
}
line2
{
cp0=-87.550247 2.423830 -259.883057
cp1=-99.846626 2.424730 -259.772278
elevation=0.000000
flags=0
}
line3
{
cp0=-87.452042 2.137570 -249.649597
cp1=-99.748688 2.139580 -249.565781
elevation=0.000000
flags=0
}
line4
{
cp0=-87.382492 1.933920 -239.446564
cp1=-99.679352 1.935680 -239.392365
elevation=0.000000
flags=0
}
line5
{
cp0=-87.344482 1.788260 -229.291824
cp1=-99.641457 1.790490 -229.270447
elevation=0.000000
flags=0
}
line6
{
cp0=-87.340881 1.647890 -219.203461
cp1=-99.637878 1.650630 -219.218048
elevation=0.000000
flags=0
}
line7
{
cp0=-87.374588 1.517550 -209.199402
cp1=-99.671463 1.520800 -209.253555
elevation=0.000000
flags=0
}
line8
{
cp0=-87.448502 1.401970 -199.297607
cp1=-99.745041 1.405730 -199.395294
elevation=0.000000
flags=0
}
line9
{
cp0=-87.565430 1.305860 -189.517548
cp1=-99.861588 1.310060 -189.654114
elevation=0.000000
flags=0
}
line10
{
cp0=-87.607132 1.183550 -179.724976
cp1=-99.904327 1.185620 -179.679321
elevation=0.000000
flags=0
}
line11
{
cp0=-87.494049 1.075280 -169.599335
cp1=-99.789719 1.076040 -169.429123
elevation=0.000000
flags=0
}

Thanks

Dave

 

[Some1]

Quick check on the use_mesh_hits

Dave, have you ever tried Fraps for recording videos?

 

[francomk]

Hi Ruud, what about ya and za angles for wipers? I think they will be needed...

 

[Ruud]

Just as a quick query, is there anything else I should be doing with the splines to make them not be driven on? Ie, do they have to be a loop, or anything else like that?

The tree shader is interesting, but as you may have guessed, it now leaves (hehe) me with lots of questions relating to best practice.
Ie, cull=none seems effective in saving polygons, and automatically flips the texture so if a tree is non-symmetric in it's texture, it appears with the correct appearance from both front or back. So a big overhang to the right hand side from the front, is overhanging the same way when you get to the other side.

I've attached the current X-tree Cg shaders. You have a point with the mirrored UV's. Perhaps the ddx() function might be any good to detect mirrored UV coordinates, haven't used them ever. In that case I could detect right->left texture coordinates and flip the normal generation.

As for the splines, I get a similar issue, but the problem is a bit more complex than it appears. All the mesh triangles are added to an AABB tree. The spline triangles are also added to that.
Now when use_mesh_hits=1, it sees a spline triangle. Instead of using the smoothed surface location, it will use the calculated UV coordinates on the specific triangle, and do a quad intersection to come up with the unsmoothed coordinates. However, that DOES mean it uses the translated spline triangle! So it does seem to use unsmoothed coordinates, but based on the spline triangle.

Normally, the spline triangle is the same as the mesh triangle so that won't make a difference. It will still find the spline triangle, but instead of smoothing things out, it will do a linear UV quad intersection for that spline triangle (plus the one near it to make a quad).

Is it problematic then if the spline triangles are exactly on the real mesh? Why would you translate the spline up or down? Normally I'd say the splined mesh is an exact copy of the underlying mesh.
Now that I say that, for a laterally tesselated mesh (rally bumps), it isn't. I'll see if I can have it search on for the actual mesh (which it does, to determine surface type, so somehow it doesn't then pick that point up).

 

[Mr Whippy]

Hi Ruud,

Yes, it'd be nice if the mirroring was possible of UVW's for trees. I spotted a practical issue right away with the non-flipped UVW's and that was that the shadow cast of the tree was different to what I was seeing. Ie, the lower two boughs of the tree in the texture are actually one bough on the other side which is casting the shadow, so the shadow on the floor was now wrong... was actually quite obvious rather than something I went looking for to find fault.


As for the splines.

Yes, the real mesh is massively important. As you can see, the splines are a flat surface, and flat surfaces are very unreal. The crown on the road in my example is probably the best case example on that road. It gets stronger in places, along with overall road cambering. It adds significantly to the best line you would take, and the feel of the road through force feedback.

This is why I have stopped using splines. They offer nothing but limiting all our surfaces to the most basic and boring type, super smooth with no character.

Unfortunately many things are tied to splines, resets, cameras, AI, map.

This is why I'd prefer splines to simply be "seen" but completely and utterly ignored for driving upon them.

I've tried in the past moving them 10m down from the road surface, but then AI has trouble, the cameras have issues, and the reset to track doesn't work either.


Splines are also weak even in their current state because they are limited to the track surface for coverage. You can't have the AI cut a corner where you would in real life, because the splines would intersect geometry which the car would then 'float' through (as in my video), which then looks weird.


I can see where splines are important for old tracks and smoothing them out, but that is, imo, their only real value. For any new content all they do is limit creativity and the enjoyability of Racers potential to do really cool and interesting things.

Turn splines into a lookup only for things like resets, cameras, AI, maps, and totally remove them from the physics part (which use mesh hits should do), and then I'll be happy.
Then they can cover larger areas than needed, so AI cars can cut corners, or they can be used for traffic.

On my road, I want to run a spline full-width one way, then loop back over the top, so AI traffic can overtake using the full width, but be set to only drive on the left half normally 0 > 0.5, overtaking on 0.5 > 1 spline position... maybe naughty AI that cuts corners... Again, you just can't even try that with the splines as they are now as they can't overlap elegantly.


These are a key feature that haven't been working for too long. Having this work in practice as intended, would just open Racer up for so much more creative use of AI, cameras, maps, surfaces etc etc... it really is a bottle neck on creativity imo!

Dave

 

[Mr Whippy]

Dave, have you ever tried Fraps for recording videos?

I'll give it a try later.

Just the iPhone is shoot and then upload to YouTube in about 1 minute.

Haven't used FRAPS in years so worth a go again. Didn't like it before, just a myriad of crappy codecs and crappy full-screen frame rates made it useless.

Dave

 

[Ruud]

For the spline issue, try http://www.racer.nl/download/racer0.8.29b.zip
It seriously changed the spline lookup - as spline & mesh triangles are all in 1 big AABB tree, I did optimize things a bit and only 1 query is done, searching for both spline & mesh, but only taking the spline intersection as the position if use_mesh_hits=0.
I've tried it on Carlswood with both use_mesh_hits=0 and 1, on the road and on grass (no spline there) and it seems to work ok, although quite harsh in the corners now.

I wonder how rFactor does it with their tesselation. The principle is the same, but keeping it fast is not trivial with all those triangles that need checking (well perhaps not much since ray 2D AABB's tend to be very very small, giving their vertical nature).

Version at http://www.racer.nl/download/racer0.8.29b.zip (only the exe)

On the trees, indeed, shadowing would be funny. Needs some other method of detection the direction of UV.x.

As for those videos, they really tend to look more real life than the actual replay probably. They look good in any case. Racer's replay movie function does work, except for sound it seems, but gives quite a bit of preprocessing to do.

 

[Mr Whippy]

Ah that seems to have worked on the splines

As for physics speed, well I've been running it both ways quite a bit (trying to get use mesh hits to work over the last year or so) and can't really see any difference, and on a smoother higher poly density course it's smoother anyway. Also, my road course has quite a bit of noise on it any way (Racers perlin type) to try give it a bit more real life road 'detail' anyway, so the mesh stepping isn't even noticeable.


My mini map isn't working so well now though, but I know there were bugs around that, will have a tinker and see what happens


Will try the tree shaders now and see what happens

The issue isn't a huge one really, but it'd just be nice to do it right while we are visiting a solution in that area. It'll also be much easier for authors not having to fight with these as much by doing extra polys for the back faces etc



Hehe, it's weird, a video of Racer in a replay looks much more real. Maybe it's the 25/30fps, the camera shake, the poor focussing, the extra level of exposure compensation (limited to just a few stops)... hmmm...

We do need different fs_filters for replays longer term, limit fps down to real film speeds and then we can get lots more effects filling the GPU power up

Dave

 

[Raphael Buthmann]

Ruud , I've got this error in 0.8.29b

Tue Dec 28 18:27:14 (WARN): [racer/4276] Car 'Mitsubishi Eclipse GT' is incompatible with this Racer version (car=0815, need 090)