Racer v0.9.0 RC6 Released

[Ruud]

It's been too long... Now the new version is at www.racer.nl/dl_beta_win.htm

I'm working on stereoscopic rendering; with Quadro's this is relatively easy, on Geforce not so much, but I've read that driver 314.07 supports it suddenly out of the box?! There should be an Oculus Rift on its way soon (these next few months?) so that should be fun.

The changelist:

- Fixed Tracked white menu background
- Camera toggling (with the C key) had an extra mode that should not be there (this was an entity mode)
- Fixed bug in shadows_f.cg full screen shader.
- dbg_car.flip_tan option removed from racer.ini.
- Fixed audio pitch bending frequency to use the original frequency of the loaded sample, instead of the audio engine output frequency.
This could lead to incorrect pitch shifts for example with samples that were stored in 48kHz but played back at 44.1kHz.
- Added warnings for missing LOD models (which could cause disappearing models when generating the shadow maps)
- Modified scaling of racer.ini's dbg_controls.throttle/brakes/clutch/steer to use normalized values (0..1) rather than 0..1000
- Added filtering around wheel (tire) forces; a 2nd order Fz Pacejka input filter (fz_filter_frequency/fz_filter_damping)
and a 1st order Fy (lateral) Pacejka out filter (fy_filter_frequency). Both in data/cars/default/car.ini.
- Also added a 1st order Fx (longitudinal) Pacejka output filter (fx_filter_frequency).
These are useful when dealing with high-fidelity surface data (Lidar or high-frequency road artificial noise)
to prevent very spiky lat/lon accelerations (giving unrealistic grip loss).
- Added dev.opengl_checks to check lots of times for OpenGL errors.
- Added dev.run_first to be able to start a command (like a batch file) before starting Racer.
- Added audio options in car.ini; understeer_oversteer (experimental) and damper sounds. See http://www.racer.nl/tutorial/car_sounds.htm
- Added spline.ini option lines.lateral_divisions to tesselate the spline laterally. This highly improves cambered curves in the road. Values around 6-20.
- Fixed panorama_f.cg shader to light up the texture (would quickly become either black or whitish, never showing the texture image itself).
- Added rtd2ascii.exe tool to convert binary RTD (telemetry) files to ASCII.
- Added fmod() and abs() functions to Onyx, next to improved error/crash reporting.
- Onyx now requires all code to be defined in functions. For independent running of Onyx scripts (onyx_run.exe), you'll need to create a 'void main()' function.
- Added friction_circle_method 10 (similarity model/Marno Hopmans variant) which accepts per-wheel lyka and lxal tuning parameters.
(wheel<n>.pacejka.lyka and wheel<n>.pacejka.lxal). These define Fy influence on slipratio (ka=kappa=slipratio) and Fx influence
of Fx on slip angle (al=alpha=slip angle). Normally you'd use values lower than 1 (and larger than 0) for these lambdas.
- friction_circle_method can be overruled per-wheel (so per-car) under wheel<n>.friction_circle_method.
- Removed dbg_car.use_slip2fc option (obsolete).
- Revised the rendering path to be able to override the main FBO's size. This for surround rendering with split rendering for all 3 screens.
See also www.racer.nl/tutorial/surround_rendering.htm
Current issues: Z-buffer is shifted between split screens (screenCenter uses screenLeft's depth buffer).
- Added quad-buffered stereo support (see racer.ini:resolution.stereo.quad_buffered). nVidia Quadro only currently; 3D Vision may follow for Geforce cards.
See also www.racer.nl/tutorial/stereoscopic.htm
- Added 'vsync <n>' command to set vsync live.
- Autoexposure data/renderer/fullscreen_shaders_hdr/luminance_downsample_f.cg now detects NaN onscreen to avoid exposure spikes.
- nvidia_perf_path added in racer.ini, which needs to point to nVidia's PerfKit DLL. See http://www.racer.nl/tutorial/profiling.htm
- Motion blur taken out for the moment by default.

-----

RC5 Buglist:

- Gearbox shift times not working properly, step from 0 > 1 clutch position over the time rather than smooth linear transition.
- Water reflection not rendering, needs clarification on functionality.
- Qlog discrepancies (I'll let Boomer clarify those).
- Odd console readouts about tyre slip angles or something popping up (same goes for gearbox manual/auto setting, doesn't need to be console displayed imo)
- PerfSDK not working as advertised, broken?
- Multiplayer joining to IP's seems glitched, the person joining has their brake stuck on and are unable to shift
- The Multiplayer Lobby does not let you connect, and subsequently let you host, despite the right ports being forwarded. (Anyone else experiencing this bug?)
- The particles pop-out of existence at the end of their specified lifetime instead of fading away smoothly. It would be nice to have some better control over the fade-in and out over the lifetime of the particle since tiresmoke starts out thick and opaque then disperses and becomes more transparent over time, while gravel or dirt fades in a bit at first then eventually fades away.
- Smoke flickers in the reflections, as though it's missing every other frame.
- Replay bugs: No smoke effects, ghost car is left on track.
- The starter sound plays all the way to the end of the sample instead of stopping when you let off the starter.
- Ghost doesn't work on endless tracks.
- track special.ini: timeline.point_to_point=1, timeline.auto_return=0 - The auto_return setting doesn't seem to work here. I have a point to point track and the car resets 3000ms (3s) after crossing the finishing line, but I don't want it to.
- No reflection in the Racer garage when selecting a car.
- The unsprung weight apparently applies a downforce, try making a 150kg rear axle with the front suspension lighter and the car will act as though it has high downforce when jumping off of a ramp.
- If the wipers are set to rotate in opposite directions then the intermittent position does not rotate back and forth smoothly. It snaps back.
- In RC5c at least, the camera bug is still evident, and on Carlswood (spline based cameras) you can often get stuck so you can't get back to the in-car camera view which is really annoying! - Courtesy of Dave

-----


The Buglist (currently known specific to RC6):

• Try going in reverse, the front brakes appear to lock. After further examination it looks like in reverse the rear tires will lose traction completely if they spin at all. Alex Forbin
• Brakes on, car pointed downhill, car creeps forward and to right. Boomer541
• The physics are screwed up, just try to drive the Baja on the Cloverleaf Highway track and compare with ver090RC5. Try the Lambo also. Details & Details 2 Boomer541
• Problems with surfaces as the water in my Surfaces and sounds track makes the car float up/down. The water under the bridge flickers which appears to indicate a problem with textures. Boomer541
• Carlswood has flickers on the tirewall tops. Boomer541
• Cars wheels go above/below the surface and can make violent bounces. Boomer541
• There are NO skid marks generated. Boomer541
• Freezing my system, forcing a hard reset.The freezing even prevents qlog from leaving any hints as to what is going on. More info in post. Cosmo°
• Physics issues, see post. Chronus
• At night, everything has a red tint to it, can also be noticed during the day on the darker parts of the track or car. Harey (due to nVidia drivers?)
• Reverse doesn't work right, seems you have to slip the clutch to get it to go in reverse otherwise you just spin your tires and sit there. Harey
• Can't run strict=1, can't check car/track for errors!!! Boomer541 post
• When trying to use tracked to check key cameras the only yellow track section that appears is with the first camera (On carlswood). the p-key does nothing and the splines are different than on ver 090 RC3. Boomer541
• The three speed wipers Don't do three speeds. pos 1 - off, pos 2 - nothing (S/B intermitant.), pos 3 - normal sppe, pos 4- fast speed. Boomer541
• In a replay if you use the console you can't send a console command because the enter key has turned into a slow-mo toggle. This means as soon as you use the console in a replay, you are stuck and need to close Racer a 'messy' way. Ie, escape key no longer exits the race. Mr Whippy
• Multiplayer broken!

 

[boomer541]

Another Bug.
When trying to use tracked to check key cameras the only yellow track sedtion that appears is with the first camera (On carlswood). the p-key does nothing and the splines are different than on ver 090 RC3.

I better stop playing with this latest version as I would probably find a new bug everyday.

 

[Mr Whippy]

Key-frame cameras are bloody horrible.

I still use the "old" cameras exclusively... well you have to because you can't mix the two types and keyframe cameras don't even offer some basic functions that you'd expect.

Authoring them is horrible too.

Not really sure what the point of keyframe cameras actually was. Had they been fully developed to be flexible and powerful then fine, but being tied to a spline, and ergo a circuit only type of course, instantly limits their ability.

We need to destroy BOTH the old camera systems in my view and start a new one based on an open coded system that allows complete freedom rather than hard-coded nature.

Dave

 

[Mr Whippy]

Well I just tried this version out quickly.

What tyre force mixing model are we meant to be using? 7 or 11?

I get the weird reversing bug with both.



Instantly that makes me wonder if other things are wrong with the tyre physics here.

Stuff has been wrong for a while now, and it just seems to be more half-implemented new systems stuck over the top of buggy old ones.

Even with the fabled MF5.2 and real data (almost perfect for my real car), it is completely and utterly unrealistic. If my road car handled anything like it does in Racer they'd all be destroyed in horrible road accidents... and that is meant to be a good tyre model with good data!


At this point I'd prefer to see the whole tyre model ripped out of Racer and start again with ONLY the system you wish to work forward with, and only the variables we need to worry about implemented.

Ie, do we still need to worry about damping predict lat/long? Optimal slip angle/ratio are STILL needed despite racer.nl saying they are not http://www.racer.nl/tutorial/combined_slip.htm because the sounds and skid marks appear to need those values so they will work properly!


We have new methods applied over old buggy methods and it's all just reached a point now where I can't even begin to try help out with valuable feedback.

It just feels like a waste of my time to try support fixing bugs when we just layer new bugs on top of old
A quick 1 minute test would have shown a glaring bug here and should have stopped the release

This version is just fundamentally too wrong with no clarification on what it should and/or shouldn't be doing (and how we use the new mixing tyre models/methods) that I can't even begin to sit down and go through what is wrong.



Even the FF feels too light and now all my cars slightly float left and right via the steering with no FF sensations while before it was super solid (I'm sure Cosmo and I even noted this issue in the RC5e/RC6 preview we had last year!)
It feels like there is a dead-zone that wasn't there before? I can't drive the Gallardo which was super stable on my road course, without falling off all the time now.


At this stage I'm sorry to say that I'm just gonna sit back and do nothing. When there are new things to test and refine or bug-fix, fine, I'll happily help. But when the sum of the last year of work is just more bugs and no progress I have no inclination to point out the glaringly obvious problems with Racer again and again hehe.


PS, the mode_dev and mode_play bat files don't seem to work properly either. I still have to wait an age for Racer to fade in and out which is even more frustrating.

Then the shadow issue is still there (blurry near camera, sharper further away)

No envmap rendered on the menu car selector shaders.


Cheers

Dave

 

[KS95]

Another Bug.
When trying to use tracked to check key cameras the only yellow track sedtion that appears is with the first camera (On carlswood). the p-key does nothing and the splines are different than on ver 090 RC3.

I better stop playing with this latest version as I would probably find a new bug everyday.

It's what you do Added.

 

[Alex Forbin]

Dave, try alt-F4 instead of esc. I've had the same complaint about exiting for a while and this is how I deal with it.
I agree about the problem of too many things being tried at once, it's bound to make things horribly confusing for Ruud as well as us.
I have pretty good luck with the pacejka 5.2 tires myself, but only with a few datasets. I've tried upping the tire stiffness a lot and it seems to help the "floating" sensation, maybe a problem there.
The FFB has always seemed to lag quite a bit to me, and this could actually be the cause of the floating we are feeling.
I wish Ruud would jump in and give us some ideas on what to chase.

Alex Forbin

 

[Mr Whippy]

Yeah having a dialogue going on would be helpful so we can work with Ruud to move things forward.

It'd be really good if Ruud could commit a day a week to going through our bug-list. I'm sure a lot of what we mention is core to what Racer is used for with the sim users too... ie, fundamental physics stuff etc!

We are in essence a free bug-testing and development resource so it makes sense for Ruud to use us. Dropping a clearly un-tested release on us (ie, you can't even reverse the car, a fundamental issue) then disappearing for a week+ without any feedback is kinda upsetting.


I really do hope Ruud will come back and take our bug-list seriously and try fix these long-standing issues... at worst they might just be back-burner things, but at best some of the fixes we are seeing must be fundamental to all users of the Racer platform!



As per MF5.2, it seems like they should be good tyres but without a proper pacejka editor that can edit the coefficients I'm not sure what I need to do. It seems like we have two MF5.2 tyre systems, one with TIR files and then another with scaling factors?
I had apparently real data and my Z4 would spin out with about 4deg steering lock in steady state driving, no chance of correction. I could add 300bhp to the car, rev the thing to 7000rpm and dump the clutch and it just bogged down and flew away without any wheel spin hehe.

Without a proper pacejka editing system (ie, let us build curves up from nothing rather than the factorised editor we have), then maybe I could make a good tyre file, but it's impossible using pacejka player right now



I think before we jump in and chase anything Ruud needs to explicitly say what he has done, what might work, what might not work etc etc... there is just too many changed things in the last year that I have no idea what is right or wrong any more (ie, we have about 10 mixing methods, about 10 new tyre tweaking variables to add, and a whole bunch of legacy stuff that qlog is asking for but apparently we don't need any more!)


Two things I really want to see

Important bugs being fixed before we see new releases. Ie, stuff that is just plain wrong, or stuff that worked before and gets broken again!

Clean up of old features/settings (keep them for the main trunk, but imo Free Racer needs to be progressive, legacy support for Free Racer just confuses development of good new content imo), and clarification on new features (ie, how exactly do they work, ie, water shader which is still broken, new brush tyre model but it's not being used in Racer.ini??)


Hmmmm

Dave

 

[Stereo]

As per MF5.2, it seems like they should be good tyres but without a proper pacejka editor that can edit the coefficients I'm not sure what I need to do. It seems like we have two MF5.2 tyre systems, one with TIR files and then another with scaling factors?
I had apparently real data and my Z4 would spin out with about 4deg steering lock in steady state driving, no chance of correction. I could add 300bhp to the car, rev the thing to 7000rpm and dump the clutch and it just bogged down and flew away without any wheel spin hehe.

Without a proper pacejka editing system (ie, let us build curves up from nothing rather than the factorised editor we have), then maybe I could make a good tyre file, but it's impossible using pacejka player right now

Hmm I thought it was about time I learned about pacejka... What sorta inputs would you want to adjust directly (instead of via figuring out which constant moves them). The B C D factors seem to correspond pretty directly to the gross shape of the curve (B governs optimal slip angle/ratio, D governs peak force generated, C governs the amount it decreases to with higher slip rates) and in turn, in pacejka87 are primarily b4, b0, b2. I haven't dug into MF5.2 yet but it seems like mainly they just become named values - rBx1, rCx1, Fx0. And where pajecka80 uses a/b for lateral/longitudinal, MF5.2 uses x/y. I haven't spent as much time looking at the MF5.2 documentation though.

Tried some papers on the brush model, can't say I understand it fully - there's a numerical instability in regular pacejka MF because it calculates everything on scaled velocities which means division by 0 at low speeds, and I guess that's avoided by using the static part of the brush model? They seem to just use MF at higher slip ratios, anyway.

Intuitively, it's strange to me that this is a function of the slip angle/ratio rather than the difference in velocities of the contact patch and the ground... like, naively I would be drawing a friction curve based on the slip speed+direction, since at higher speeds you have to turn the wheel less to get the same amount of lateral slipping. I guess I have to trust that it all works out, but I'd like to get to a deeper level of understanding of how the magic formula's applied. If it was just based on relative movement of the contact patch, it could just be a regular friction force, acting opposed to the movement.

 

[Mr Whippy]

Yeah the pacejka curves are pretty straight forward. If you read the Hans Pacejka book on Google (read inside feature), you can cover off most of the tyre model elements and thoughts and get a feeling for what it's all about.

MF5.2 is indeed simple too (generating basic curve shapes), but the pacejka editor, from what I remember, only accesses the scaling parameters. You can't build a 'wrong' tyre this way, but it seems the default 'right' tyre is wrong to start with, which doesn't help.


I think the big issue with pacejka is mixing forces from lat/long. Pacejka 89/5.2 are all steady state models too, so when things change, I don't think any concessions are made for how they change. Ie, bounce-back of forces in tyres etc.

Right now for example we have vertical tyre spring/damping, so the contact patch and thus load at the contact patch can be somewhat mobile. However, the lateral spring isn't there, nor the longitudinal. Our tyre appears to be (as far as I can gather) completely rigid in those two dimensions. That can't help with snappy behaviour.
I think that is where the old damping predict lat/long and length values etc came into play a bit, damping the values that the pacejka equations were exposed to vs time.

However, why not simulate those elements with actual spring/damping models like the vertical tyre features? We have the CPU power now vs over 10 years ago I think when Racer first starting using pacejka heavily vs crv file LUT's.


Then we also have a question mark over mixing. That suddenly gets maths heavy. I'm happy for Ruud to run with whatever works, but it feels like nothing works. Throw in the weird reversing issue we have now, AND the old diff issue with cars not reversing either, and we start to wonder what is just bugs or bad values on our part.


Then we also have Mz stuff. Mz is implicit to the leverage of the tyre forces about the tyre axis. Ie, Fy vs scrub radius.
So pneumatic trail that is currently hard-coded by us, should ideally be dynamic (it's simple trig based on caster and distance and tyre rolling radius + load, so no idea why Ruud hasn't fully implemented that feature)...
Then we have the dynamic movement laterally that isn't evident. Ie, tyre will move left/right a few centimetres at high lateral loads, and that means the Mz should change a lot too... but our super solid tyres in lat/long allow no movement there either.
We get a simple static KPI offset value for lateral offset about steer axis. Even ignoring kinematics in the suspension, the tyre vertical deformation will change that offset value, never mind lat/long deformations we are missing too!

The Pacejka book even says Mz is a function more of Fy any way, so really we should calculate Mz from Fy and the contact patch vs steering axis offset.

Mz actually confuses tyre development a lot because the 'feel' is really important but right now we just have the feel through the wheel totally made up vs what is really going on.


Personally I'd love to see the KPI/Castor angles used, an offset for the hub added, and then ALL the wheel kinematics for steering can be done properly.
The trail offsets in all three axis can then be managed properly. We can then maybe add springs for lag/long and damping for lat/long, just like we have for vertical tyre rates.

We can then take Mz from Fy instead, and probably get amazing feeling cars.

I'm sure this is all actually fairly simple to do because it's mostly explained in the Pacejka Book!



But as per mixing, I have no idea really. It's turning static steady state tyre models into being useful for dynamic conditions.
This is where you just need to have a good reliable (read bug free) physics to start with that is doing everything reasonable to get good numbers to the pacejka model (ie, what I mentioned above about KPI/Castor)... at that stage you can make a car that is accurate, and then you can develop tyres for it knowing it's reacting properly.


Even with the best car.ini and pacejka right now, there is too much wrong with Racer from a combo of bugs and bad systems to make really convincing highly realistic cars.


We can make nice stuff there is no doubt, and if you didn't know what was going on underneath you'd be pretty happy with it. But as someone trying to make physics for cars it is very often just a case of ignore reality and plug in values to make things 'feel' right even though they are wrong.

Racer should be the best thing out there, and it always just feels a few months of hard work away from being just that. It just never seems to get there which is a great shame


Come on Ruud

If you just finished up the basics properly and ironed out these bugs you could probably almost make a proper game out of Racer as it stands if you really wanted. It's so close, it's just these rough edges that hurt making final usable really top quality content

No mean feat really... and Racer is still great. I'm somehow here 11+ years later still tinkering with it. It is good. But it can be better

Dave

 

[Stereo]

Then we also have Mz stuff. Mz is implicit to the leverage of the tyre forces about the tyre axis. Ie, Fy vs scrub radius.
So pneumatic trail that is currently hard-coded by us, should ideally be dynamic (it's simple trig based on caster and distance and tyre rolling radius + load, so no idea why Ruud hasn't fully implemented that feature)...
Then we have the dynamic movement laterally that isn't evident. Ie, tyre will move left/right a few centimetres at high lateral loads, and that means the Mz should change a lot too... but our super solid tyres in lat/long allow no movement there either.
We get a simple static KPI offset value for lateral offset about steer axis. Even ignoring kinematics in the suspension, the tyre vertical deformation will change that offset value, never mind lat/long deformations we are missing too!

The Pacejka book even says Mz is a function more of Fy any way, so really we should calculate Mz from Fy and the contact patch vs steering axis offset.

Mz actually confuses tyre development a lot because the 'feel' is really important but right now we just have the feel through the wheel totally made up vs what is really going on.

Yeah, the Mz stuff sorta stood out to me as odd having it in tire calculations (since the mechanical trail changes the axis it should be calculated around and thus it should really depend on suspension too); pneumatic trail seems to be implicit in the Mz calculation used. Really Mz should be combined Fx (forward) + Fy (sideways) + Fz (up) converted into torques around the steering axis - due to KPI and caster the Fz can't be completely ignored, and as you said, under deformation the Fx is gonna come into play. Heck, torque steer is at least partly because of the Fx contribution being non-symmetrical. I imagine Fy is the largest component, but it's not 'real' if you just skip some variables.


I guess it's hard to measure high slip angle/ratios empirically; I would expect the method of combined slip to come into play more at those rates. And I can't see how pacejka MF would even expect to get the right answer when the car is going sideways; Vx drops to zero making the slip ratio infinite and the slip angle 90 degrees. If it then goes past 90, the slip ratio becomes negative infinity suddenly. Which just contributes to me thinking 'slip ratio' isn't a good way of thinking about how fast the tire is sliding in general terms - as the car turns sideways, regardless of how fast the tire is actually skidding, the slip ratio goes to infinity.

Haven't yet looked at the actual Pacejka book though, just the Adams/Tire documentation (which was available online and describes the tire models fairly well). Hopefully it'll answer some of my questions like 'why slip angle'.

 

[Mr Whippy]

Arghhh, just copied my rc5c bits back and my cars float sideways heavily and appear to have no grip.

racer.exe and racer.pdb clearly are not enough to 'back up' Racer versions these days.


Now I need to spend some time reverting all the files just so I can use Racer again hehe.


I must say, I've just been driving my Gallardo which was stable and great, on a narrow road course again, and it's really floating all over the road. It just seems to have no stability from the front tyres. Left a bit too much, then right a bit too much, and so on. It even does it with a mouse/keyboard so it's independent of the controller input force feedback loop or something.

I mentioned this above, and it was also evident in a Racer preview (rc5e?) from Ruud, although it was much more noticeable in the preview to the point you couldn't even drive down a quarter mile run without hitting one side or the other

This is subtle now but it's still completely ruining any kind of precise driving style. I'd class it as another bug, because these tyre curves are about as right as they come, so I can only put it down to a not so good new tyre model/mixing model or something?!




I totally agree Stereo, Mz seems really fudged for now. Yet it's completely reliant upon the cars natural feedback loop and balance. If you get wrong forces and you react to them, or the wheel moves as if certain forces exist, and they don't really, then you are going to move the car steering unrealistically.

Ultimately though, a load of knowledge is useless, because with major bugs present it doesn't allow you to refine the model we have.

RC5c seems to be still the last reliable version for tyre stuff... though that reverse diff bug in that version, and this weird spinning tyre reversing bug seem too related to even rule out odd pacejka behaviour in RC5c imo!


Hmmm

Dave

 

[Mr Whippy]

FYI, anyone going back to the old version and noticing floaty cars, it's something in the default car.ini file.

There is a whole load of variables you might want to check in the new car.ini (default) for tyre modelling stuff.

Maybe some of these defaults are not so good.



I'd really like Ruud to clear out old legacy stuff and then clarify the exact requirements and logic of these tyre config variables. Some sound common sense in description but others don't and that makes it harder to tune them with any kind of understanding on the expected outcome.

If we knew what they were actually doing in the tyre code flow then we might be able to fix many of these issues we are having (assuming that default car.ini coefficients/settings don't suit all cars!)

I might have a play again later, BUT, I still think something fundamentally is broken somewhere... and as I learn more about the Mz stuff and steering kinematics I don't think I'll be fully happy until we get a better steering/Mz model for our FF wheels... Please Ruud

Hrmrmrmrmrmmmmmmm...

Dave

 

[boomer541]

The bug "The physics are screwed up, just try to drive the Baja on the Cloverleaf Highway track and compare with ver090RC5. Try the Lambo also. Boomer541" Needs a little more info.

I went way back to when I made a track tutorial and remembered a problem with bridges. the problem is at the point where the road surface has nothing under it that makes a car bounce violently.

By extending the verticies on each side of the road at that point down to a ground or suppot poly the problem is minimized but not entirely removed. Also raising the road suface at that point will also minimize the problem.

In the 090 RC3 version it wasn't very noticeable but the versions afterwards exacerbate the problem.

I used this effect once with sand by placing a layer a short distance beloy the sand surface which allowed the car tires to sink into the sand. It was very efffective but it screws up bridges if there isn't something supporting the road surface properly. Anyway, it needs work.

Also noted that the C-key cameras in 090 RC3 worked properly without Qlog errors but ver 090 RC4 thru 090 RC6 gave a Qlog error. That's an easy fix Ruud, Just use the C-Key code from ver 090 RC3 AND DON"T CHANGE IT!

 

[Alex Forbin]

The fact that your post is the first in a solid week for this new release, should pretty much indicate the current state of Racer "development".
Bug: The reverb sound effects seem to be broken now.

On a positive note, the smoke looks much better now, nice clean fades.

Alex Forbin

 

[boomer541]

Another bug!
The three speed wipers Don't do three speeds. pos 1 - off, pos 2 - nothing (S/B intermitant.), pos 3 - normal sppe, pos 4- fast speed.

 

[Alexander Knoll]

hmm...not sure if it's a bug or a update...but it looks "wired" to the old ons...

 

[William Geuze]

This is an update, the splines are now divided laterally to counter bumpiness in high camber corners. The problem was due to large/long triangles in these kinds of corners would stretch a too big of an area when the inside was at more of an angle than the outside of a corner. In essence, the goal is to make the polygons as planar as possible, reducing awkward triangulation, like below:

Increasing resolution laterally, diminishes triangulation like on the left because distances are shortened considerably. For this to work well, you can increase resolution in the visual road surface as well

The amount of divisions you can set in spline.ini

 

[Mr Whippy]

Yep lateral spline sub-d's are good, more so I suppose for tracks where the mesh density is fairly low and that is used to build the spline mesh from.

Where we have older tracks that have such low poly density then this is a welcomed addition.

I'm not sure it's so useful for newer higher density courses though. I'd still like to hear about turning our meshes into lidar format data for the physics engine to use...
Also maybe having a way to split splines for multi-layout/optional courses too. They are great for circuits for racing but struggle with other uses.

Dave

 

[William Geuze]

This goes both ways. When a track is so low res that the wheels lift off the visual mesh, but stay on the spline, I'm not sure that is a good thing. Same thing when the wheels go through the visual mesh. Either way, you want the visual mesh to have a higher resolution than the spline mesh, at least bilaterally, as there smoothing between bilateral splines going on. You notice this when driving on just polygons vs polygons and a spline.

As far as 'lidar' format for community tracks, I honestly don't see the point.

 

[Mr Whippy]

I think the issue is we have three approaches, each with strengths and weaknesses.

We have splines, but with splines we can't have a split (say for a rally-cross track with a choice of routes). We also have a fixed linear cross-section only. I'd argue that very few race tracks are actually linear cross-sections and given a decent modder they may want to author in appropriate convex/concave track features, or the stepped bends we see in a few places on the 'Ring for example.
They are however super smooth to drive on and feel great. The problem is when we want something other than super smooth.

We then have 'use mesh hits' which is the best for free-road roads and bumpy courses. We can then use splines to guide AI and resetting only... though we still are limited usually to a linear course if we want to use the splines for that purpose.
This feels great for certain tracks, but sometimes we have smooth tracks/roads with significant crown or convexity, with occasional bumps etc.


We then have lidar meshing... I suppose where an author wants to be creative with bumps and surfaces (say a rally track or something where they want to add a lot of 'feel' to the surface with pot holes etc) then they can benefit from this. With this method you should in theory be able to make a really great rutted course for 4x4 trial driving or other cool things like that! You could really add in some great detail without worrying about GPU poly count and memory usage!



In one example I have made a real road and it is just plain wrong if it's flat (no crown to the road). If I use 5 quads to define the width and drive on the mesh I can clearly feel the FF at different front wheels changing as I move across the road. Crossing from the left to right hand side is quite bad as the FF snaps from left weighted to right weighted all of a sudden.
If I make the cross-sections about 15 instances then the snap is reduced and it's smoother. At 20 cross-sections it's feeling really good.
At this point I can add pot holes and camber and dips and bumps and so on... But the mesh is just getting too dense and high polygon.

That is where the lidar mesh comes in for me at least. Maybe they can fill in the gaps of the two systems we have.



If by "community tracks" we mean super-smooth race courses only, then I can't see the point in lidar either.

But Racer has scope way beyond super smooth race tracks, and many authors try innovate with content that could be made all the better by using techniques like the lidar data technique.



Unfortunately for Racer a great deal of the content produced isn't glass smooth race courses and splines don't cut it as they stand now.
If there were a way to basically provide Racer with a mesh that it treated as a spline, but could have varied cambers and cross-sections etc (like the current sub-divided one, just we define those sub-divided verts!) then I'm sure they would be much more popular again

But even that still doesn't avoid the problem with them being completely focussed on classic circuit racing. As soon as you leave the realm of something like F1 and try do a rally course, or super special, or rally cross, or a road etc, then you are stuck




I say limit Racer by the authors imaginations to innovate with ALL the features Racer offers.

I wouldn't say I don't see the point in lidar for community tracks. I'd say, lets see what the community can do with lidar on their tracks!


Dave

 

[luthobu]

Thanks Ruud.

Rendering, shaders and FPS: A+ It inspired me to complete Elan Valley.