Racer v0.9.0 RC8 Released

[Cosmo°]

A new beta is available at http://www.racer.nl/dl_beta_win.htm.

The changelog:

v0.9.0 RC8 (01-11-2013)
-----------------------
- Added 'float eye' passing to fullscreen shaders (postprocessing) as a Cg uniform (0=left/1=right).
- Modified shadowmapping.cg; it could compile badly due to iSqrtSample being used as a constant
and a local variable in one line.
- Added 'splitter' console command in Racer itself. I.e. 'splitter 500' will do a 500x500m grid split
from <trackname> to <trackname>_split. Copy the track itself first from <trackname> to <trackname>_split
and let the splitter overwrite things in the _split version of the track.
- Added 'atlas optimize' command, to generate an atlassed version of the track in <trackname>_atlas.
Much like the splitter above (first copy the track). Not fully working yet.
- Added dev.argument_tracing option in racer.ini for explicit argument stack tracing. Only useful
when you have a crash that requires more information than just the function stack trace. Only
a few arguments are supported inside Racer. Slows down the program if used.
- Const sized arrays in Onyx are now possible: const int MAX_ELT=5; int a[MAX_ELT];
- Font rendering now much more crisp.
- car.ini wheel<n>.tire_model.relaxation_length_lat (and _long) of zero is now accepted (uses instantaneous slip angle/ratio)
- Onyx fork() command to spawn off SPU processes.
- Onyx improvements; peephole optimizer, #ifdef/#define/#else/#endif, #error "message"
- Onyx deg2rad(), rad2deg(), atoi(), atof(), split(), acos(), asin(), atan2(x,y) functions.
- Slipratio clamping in car wheels is now configurable in racer.ini: dbg_car.max_sr (defaults to 1.5)
- Combined slip method #10 (SimilarityMarno) is a validated method that is being used in production at Cruden.
It still isn't optimal though when trying to get drifting cars for example.
It uses a mix using slipRatio and slipAngle (slip=length(SR,SA), Fx*=SR/slip, Fy*=SA/slip).
- Added ProcessCount(), deg2rad() and rad2deg() internal functions to Onyx.
- Improvements for the DirectShow replay exporter; replay.video.muxer, replay.video.yuv_convert
Codecs are still an issue; the Windows Media 9 one seems most stable for now (but slow).
- Added racer.ini replay options for automation of replay movie files (requires dedicated configuration files).
- Added Cg shaders for the simple polygon shadow underneath the car.
- Fixed atmosphere extinction for a lot of the dyn_*.cg shaders.
- racer.ini's gfx.check_opengl_errors is now collapsed into dev.opengl_checks.
- Added car.ini body.yaw_damper magic torque for drifting car control.
- Onyx 'continue' for for/while/do-while/loop.

 

[Mr Whippy]

Ah ok had a proper dig through.

An entirely new sky shader is being used here.


It looks pretty good, but the default values are a bit off, and the implement doesn't seem complete yet.
Ie, the sky brightness having a value of 12.5x as a factor for kLux seems wrong. The default value range of 0-4 seems much better.

Ie, the end result of the sky appearance is a factor of the sun colour we set in the TOD curves.
Really it should be the other way around, the sky colour should determine the kLux value we get. Ie, automatic.



The sky demo using this technique looks fine, but trying to squash it into the Racer lighting system is breaking both this sky and the Racer lighting system resulting in un-matched skies and still wrong lighting.



Ruud, all you really need to do is take the sky demo values and put them into the TOD curves.
Then sample the sun disc value (rgb) and pass that to the kLux value for sun diffuse.
Then sample the average value of the sky dome for the sun ambient value kLux.

We shouldn't be setting kLux for diffuse/ambient at all because the sky determines those values for us when it's rendered.



Also right now ground objects don't blend well with the sky appearance because the ground is still using the old scattering system for extinction (ie, mie/ray change the ground appearance but not the sky!)
Or maybe it's using a combination of both. I assume this is half implemented at this stage, but forcing out the old mie/ray sky results in beautiful extinction colouring from the new sky.

Ie, it looks like sky clarity is rayleigh, and pollution is mie... so we no longer need the 'old' ray/mie...

The current extinction calc is using the new sky AND the old mie/ray too... The new sky is doing all the atmosphere calcs we need it seems, so why retain the old ones too?


Thanks

Dave

 

[Mr Whippy]

Yeah more looking, this isn't ideal.

Trying to take our existing curves for TOD diffuse/ambient and put them into this new system seems really backwards.

The sky should generate these values for us, not us feeding our made up ones into the sky model arbitrarily. We are taking a working sky model that gives good values and then telling it to make them wrong.

Changing the sun diffuse TOD crv to a red tint shouldn't tint the sky red. The sky should be tinted red because of the sky parameters, and that should make the sun diffuse value red.

Obvious problems with this workflow are that if the sky visually looks X amount of red already, and you then need to up the red kLux value to make it look balanced, it adds MORE red to the sky appearance, so you are in a feedback loop you can't correct. The only end result is that colour balancing can look wrong and never be right.


Lets hope Ruud realises this is a really backwards way to work, just generating more room for inconsistency and error, and work-load for track makers and artists.

This system could just be a few simple curves and fully automatic and look excellent.

As I say this is all WIP by the looks of things so hopefully it'll change and take on a more logical direction and be fully automatic with only authors/artists tweaking for style rather than painstakingly balancing a wrong system.

Thanks

Dave

 

[Alex Forbin]

I like the brush tire model, you can actually hear it skipping across an uneven surface in a hard turn.
The force feedback seems to feel better as well.

Alex Forbin

 

[Mr Whippy]

I like the brush tire model, you can actually hear it skipping across an uneven surface in a hard turn.
The force feedback seems to feel better as well.

Alex Forbin

I've noticed smoke coming off tyres more as they skip off the surface etc... it's all feeling pretty nice here. Also with more fps = better feel too it seems.

The only downside really is that smoke comes instantly, some kinda simple model like GT5 would be nice where slip x time generates a heat factor which leads to smoke... that way micro-slips go un-noticed and we only get smoke when we really burn-out the tyres


Dave

 

[Cosmo°]

I'm also getting the behavior Alex Forbin described, vehicles having forces acting on them when the wheels leave the ground, apparently motivated by the bumpstop/reboundstop damping.

Another thing, the engine starter sound is played twice in a row.

An old 22kHz engine audio sample I'm fond of has been acting up ever since an audio update last December, playing only half the range. I asked about this before in an email a year ago, but haven't gotten an answer yet - any chance to keep these 22kHz samples running as before?

Also, to add a bit more info to my repeated questioning on the combined slip calculations: I re-read the corresponding chapters in Pacejka's book, as they're referrenced in the documentation, but I still don't see how the actual Racer implementation is done. I want to visualize the friction "circle" in my spreadsheets so I can do more efficient setup work and cross-check ingame behavior, though descriptions like "similar to", "based on" don't really tell me the actual formulae.
With different friction circle methods available and up for trial, there are a lot of car.ini parameters we need to keep track of already, so any additional guesswork we need to do in this area complicates matters immensely and does little to help understand and make progress.

 

[Mr Whippy]

Cosmo, I'll happily re-sample the audio to 44khz for you.

OK we are interpolating some samples which is kinda a waste but I'm sure the overhead these days isn't a huge worry.

Doesn't sound too good with the floating physics stuff. Hopefully just a missing +/- sign somewhere hehe.


For now I'm focussing on the graphics stuff. This new sky system is showing some great promise if it's all fully implemented and the 'old' one abandoned.

Hopefully I'll find time to create some proof of concept images/skies to make it clear to Ruud why the logic needs to be reversed, because as it stands it'll be impossible to get realistic looking and skies with correct values running like it is now!

Dave

 

[Alexander Knoll]

yep Cosmo° you are right...the start sample is looped 2 times...i was sure i made a fault some where...but good to know i'm not alone...

 

[boomer541]

Thanks for the update Ruud! Looks like a lot of the bugs in the previous release have been fixed.

Thanks for fixing the terrible bounce that occured when I drove over a bridge support.

Carlswood has no splines, no trackmap. I figured out tracked missing the .dll in it's folder.

Now I'll go check to see just how many of the bugs have been fixed.

 

[Cosmo°]

Since the pacejka player too has been relocated into a subfolder it's also looking for cg.dll and cgGL.dll in the wrong place still, just like boomer reported for tracked.

Until the magic forces shooting vehicles into space feature is fixed, I'll have to go back to RC7, there's no way to do any physics development in RC8 right now, I'm afraid.



Alex Forbin: When you say you like the brush model, did you set anything other than the friction_circle_method to 11? I'm not having any luck with that, excessive wheelspin and juddering occur. Similarly, the low speed noronha model doesn't let the vehicle move much at all. Tested with a car.ini up to date and qlog clean.

 

[William Geuze]

I'm checking with Ruud what could cause of the weird forces. Can't promise anything about a quick fix though, we're extremely busy at the office but we will try and look into it.

edit:
Quick notice. From what I understood, in the suspension modelling, some clamping has been introduced to make sure the spring forces can't exceed the physical spring housing/go past the bump stops. With suspensions not set-up correctly or overly soft problems can occur. This is how I understood it, maybe someone who has a clue about this at all has enough to go by for now.

 

[Cosmo°]

I can see that compared to previous betas, the minlen and maxlen values are now actually adhered to, so if I set maxlen=0.250 it will not extend beyond that, whereas up to RC7 it might have gone to 0.252m ingame for example.

The odd forces seem to occur when bumpstop_damping/reboundstop_damping are used. I had a look at the documentation again, to doublecheck my interpretation of them was still correct and there is no mentioning of the damping aspect in that section on the homepage. The default car.ini doesn't explain whether the damping is applied similar to the spring rate, in a linear fashion related to the displacement of the unit, but at least it shows a conventional unit is used. In any case it looks like there are some free forces doing their thing, maybe the clamping code snippet unleashed them.



By the way, the default car.ini still shows an incorrect example for maxlen versus restlen relationship - we've talked about the concept of spring preload extensively in early 2009, which is why it's been available in Racer since then, restlen should be higher than maxlen by definition because it denotes the effective length of the spring with no forces applied.

 

[Mr Whippy]

I'm not sure if anyone looked, but the new sky example is here:

http://blog.cloudparty.com/2013/09/25/stunning-procedural-skies-in-webgl-part-2/

In the explanations it talks about generating the colours/values to light the scene objects from this sky.

It'd be good to just dump the sun diffuse/ambient TOD curves and let this new sky power those values. Ie, make it sunset time, the sky goes sunset looking, and the lighting changes suit to follow.

Hopefully this is what Ruud has in mind for this sky! Very excited if so


Dave

 

[Alex Forbin]

Since the pacejka player too has been relocated into a subfolder it's also looking for cg.dll and cgGL.dll in the wrong place still, just like boomer reported for tracked.

Until the magic forces shooting vehicles into space feature is fixed, I'll have to go back to RC7, there's no way to do any physics development in RC8 right now, I'm afraid.



Alex Forbin: When you say you like the brush model, did you set anything other than the friction_circle_method to 11? I'm not having any luck with that, excessive wheelspin and juddering occur. Similarly, the low speed noronha model doesn't let the vehicle move much at all. Tested with a car.ini up to date and qlog clean.

I have to agree about unfortunately not being able to do much with the current version until the "ghost rockets hehe" are gone.

On the tire model all I did was change to method 11, but I'm also using Pacejka 5.2 data so that's probably the difference.

Alex Forbin

 

[latrippa91]

how to solve this graphic bug ?

 

[William Geuze]

Are you using custom cg shaders for the car?

 

[latrippa91]

yes, also the map using Cg shaders ... On rc6 I never had problems like this ...

 

[latrippa91]

this is the qlog...

 

[William Geuze]

These ones do seem dangerous, amazed that rc6 didn't give you trouble about this actually:

Mon Nov 04 22:34:52 (WARN ): [racer] QInfo: { without groupname [qinfo.cpp:384 / QInfo::Read]
Mon Nov 04 22:34:52 (ERR  ): [racer] QInfo(data/cars/alfa_romeo_giulietta/car.shd); more '}' brackets than '{' near line 15 [qinfo.cpp:404 / QInfo::Read]
Mon Nov 04 22:34:52 (WARN ): [racer] QImage:ReadBMP(data/cars/alfa_romeo_giulietta/undercarriage.bmp); unsupported #bits (32) or compression (0) [qimage.cpp:1495 / QImage::ReadBMP]

Because of a change in the zbuffer depth stuff changes have been made to shaders, I'm not totally into shaders though.. I suggest trying everything with the supplied shaders first, troubleshoot that first and clean up that car. All those buggy dof exports surely don't help either

You can always send it my way if you like and I can take a look if you want.

 

[latrippa91]

the strange thing that the rc6 has the same configurations of rc8.
same car and the same map on RC6:

 

[boomer541]

latrippa91:
Try a different track, Carlswood doesn,t look good on my system and may have sonething wrong with it.

And you are using an ATI card?