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.

 

[latrippa91]

all tracks and cars don't look good... Yes I'm using an ATI card.

 

[Ruud]

öhm...the shaders are flickering behind/under the car...looks not so good...
Alex

Indeed, that is the shadowmapping updating that is different for each cascade (of which there are 4). In racer.ini, set all these to 0 (for profile0 and profile1):

splitrenderjump0=0
splitrenderjump1=2
splitrenderjump2=4
splitrenderjump3=6
; offset the framecount for jumping frames
splitrenderoffset0=0
splitrenderoffset1=1
splitrenderoffset2=2
splitrenderoffset3=3

 

[Ruud]

I also just noticed max view distance is 750m which is stupendously short. The other end of long straights on tracks is disappearing here haha.

But it says this should match constants.cg which actually has it set at 50,000m!

The 50km visibility is a left-over from some experimentation to let go mostly of the far plane. So indeed far=50000. There are some #define's in all Cg shaders now that pertain to LogZ. A LogZ is then written into the Z-buffer, which is far better than the default Z. With that, Z-fighting becomes better and you can use far=50000 and still not get into trouble with Z accuracy. Something I want to add in the future; and indeed then control things mostly through LOD.

 

[Mr Whippy]

Ah ok sounds good Ruud

LOD is a really great way to cut down on batches... ie, on my runway course I had about 300 cones but obviously to have them movable means a batch each.

But cones are pretty small so LOD = 200m allowed me to only be running maybe 40 batches worth of cones at a time and the end result looked the same most of the time!


It seems there is a big thing about PC's and DX/OGL and CPU limitations on batching which is slowing down PC hardware (ie, single core or not very optimised multi-core batching) vs consoles with direct programming to the graphics hardware.

Apparently the ATI Mantle API might make things much better there. I think Nvidia might use it too... hehe

I think LOD's is gonna be an easier way to manage batches in Racer vs a new API

Dave

 

[Ruud]

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.

Indeed, those DLL's can be a bit pesky; they seem to be globally defined at my PC so if they're not around, they're taken from some global directory. I should use 'depends.exe' to check where all the DLL's are coming from.

On the magic forces, try downloading this: http://www.racer.nl/download/racer090rc8b_exe.7z , which contains the same exe (slightly newer) with the suspension option OPT_HARD_LIMIT_MIN_MAX turned off. This lets the suspension run free. With it turned off, the springs can go beyond minlen/maxlen, which wreaks havoc with hard kerb-hitting, and also some cars that have bad minlen/maxlen definitions.
With the original RC8, the option is turned on to avoid wheels getting loose, but indeed there is a problem with that. I'll have to check what the forces are doing. Bump/rebound damper could indeed be a good contender, but I want to get to the bottom of it. Have to get back the Physics track for the ramp. ;-)
I'd like to keep the option on (so hard-limit suspension movement) to avoid exploding wheels. We had that with a monster truck with large wheels, which could explode.
One symptom I might have seen today was a car that jumps over a hill will pitch (backward in this case) much more than you'd expect.

On the formula itself, some tweaking has been used; Pacejka uses k/(1+k) where, again, (1+k) becomes unstable (zero) at wheel locking so yet again the whole formula goes out of whack there.

Method 10 (not 11!) does this:

  const float shfx=0,shfy=0;  // Future - fetch from Pacejka definition
  float tkappa,talpf;  // Temporary for slipratio/angle
  // Note that 'slip' somewhat assumes that tkappa and talpf have similar ranges,
  // otherwise it would stray from being a circle.
  float slip;  // Friction circle
  float gxAlpha,
  gyKappa;
  float kappaEq,alphaEq;  // Equivalent slipratio/angle as new Pacejka inputs

  // Circle inputs
  tkappa=slipRatio+shfx;
  talpf=slipAngle+shfy;  // How far out on the rim are we on the circle?
  slip=sqrtf(tkappa*tkappa+talpf*talpf);  // Friction circle
  // Cap at maximum slip length
  if(slip>maxSlipLen)
    slip=maxSlipLen;

  if(fabs(slip)<D3_EPSILON)
  {
    // No slip; just use the pure forces for this step
    return;
  }

  // Longitudinal scaling
  gxAlpha=(fabs(tkappa)/slip)/pacejka->GetLXAL();
  kappaEq=slip*d3Sign(tkappa)-shfx;

  // Lateral scaling
  gyKappa=(fabs(talpf)/slip)/pacejka->GetLYKA();
  alphaEq=slip*d3Sign(talpf)-shfy;

  // Avoid increasing the pure forces
  if(gxAlpha>1.0f)gxAlpha=1.0f;
  if(gyKappa>1.0f)gyKappa=1.0f;

  // Recalculate using new normalized inputs
  pacejka->SetSlipAngle(-alphaEq);
  pacejka->SetSlipRatio(kappaEq);
  pacejka->Calculate();

  // Forces are now scaled from the pure results
  combinedFx=gxAlpha*pacejka->GetFx();
  combinedFy=gyKappa*pacejka->GetFy();

Note that mathematically, kappa (SR) is a ratio of slip velocities (Vwheel/Vroad) and tan(alpha) (alpha=slipAngle or SA) is a ratio of Vsy/Vx. So really you'd want to combine with slip being the length of the vector SR and tan(SA). However, SR stays within control (-1..3 for example) but tan(SA) goes up to infinity when SA goes beyond 40 degrees.
So the above code, which really scales tire forces based on the amount of slip in either direction, started favoring tan(SA) when SA becomes large. This in turn made the car land into a synthetic cushion, since if tan(SA) is much larger than SR, most of the force goes towards Fy (lateral), reorienting the car.
This does not seem logical, so we took out the tan(SA) and use SA instead, which is more well-behaved. So these are the lines talpf=... and alphaEq=... which now use SA instead of tan(SA).
The cushion disappears but combined slip is still ok.
Add to that the new yaw_damper and you can control heavy spins more easily...

 

[Alex Forbin]

Thanks for the replies Ruud.
I just tried the new .exe and it works great, all weird forces are gone.
For others watching, you will need to get rid of your bumpstop/rebound rates and damping
and just use the bumpstop/rebound length.

Alex Forbin

 

[Mr Whippy]

So the new exe fixes the problems, but we still need to remove the bumpstop/rebound springs/dampers?

I guess it's something we generally don't need as mostly I've never had any issues with springs getting overly compressed/extended. Yes nasty stuff can happen if you hit kerbs but generally if you hit a kerb that hard IRL that your wheel goes up it at speed you'll probably not be driving away with a working car

Ie, the springs can go beyond min-length in real life, as a result of a mechanical failure

Dave

 

[Alexander Knoll]

hmm...i have a strange green color after the change to 08b...
same car, shader, track...
rc08

and rc08b

...what does i wrong?
please help...

@Dave
hmm...with the rc08 stereo's rx7 works like a charm... after the change to rc08b i get a fatal racer crash every time i hit a curb or drove over a bumpy grass....

Qlog parts:

Tue Nov 05 20:04:16 (INFO ): [racer] Loading car 'mazda_rx7_final' [rcar.cpp:964 / RCar::Load]
Tue Nov 05 20:04:17 (WARN ): [racer] No AI found for track garage1, car mazda_rx7_final (also no ai/default.ini) [railines.cpp:130 / RAILines::Load]
Tue Nov 05 20:04:17 (WARN ): [racer] RCamera: camera0's offset and offset_to are too close - move them apart [rcamera.cpp:349 / RCamera::Load]
Tue Nov 05 20:04:17 (WARN ): [racer] RCamera: camera4's offset and offset_to are too close - move them apart [rcamera.cpp:349 / RCamera::Load]
Tue Nov 05 20:04:17 (ERR  ): [racer] wheel0.tire_model.damping_speed = 0.000000, but must be non-zero, like 0.15 (using 0.15) [rwheel.cpp:1083 / RWheel::Load]
Tue Nov 05 20:04:17 (ERR  ): [racer] wheel1.tire_model.damping_speed = 0.000000, but must be non-zero, like 0.15 (using 0.15) [rwheel.cpp:1083 / RWheel::Load]
Tue Nov 05 20:04:17 (ERR  ): [racer] wheel2.tire_model.damping_speed = 0.000000, but must be non-zero, like 0.15 (using 0.15) [rwheel.cpp:1083 / RWheel::Load]
Tue Nov 05 20:04:17 (ERR  ): [racer] wheel3.tire_model.damping_speed = 0.000000, but must be non-zero, like 0.15 (using 0.15) [rwheel.cpp:1083 / RWheel::Load]

and:

Tue Nov 05 18:52:00 (INFO ): [racer] Bad wheel 0 force -1.#IND00 -1.#IND00 -1.#IND00 [rbody.cpp:1409 / RBody::ApplyForces]
Tue Nov 05 18:52:00 (INFO ): [racer] forceRoadTC=-0.000000 0.000000 0.000000 [rbody.cpp:1410 / RBody::ApplyForces]
Tue Nov 05 18:52:00 (INFO ): [racer] forwardWC=-1.#IND00 -1.#IND00 -1.#IND00 [rbody.cpp:1411 / RBody::ApplyForces]
Tue Nov 05 18:52:00 (INFO ): [racer] sidePrjWC=-1.#IND00 -1.#IND00 -1.#IND00 [rbody.cpp:1412 / RBody::ApplyForces]
Tue Nov 05 18:52:00 (INFO ): [racer] Going to crash, reason: wheel force NaN [qdebug.cpp:429 / QCrash]
Tue Nov 05 18:52:00 (INFO ): [racer] Crash detected, dev.argument_tracing=0 so no argument stack [main.cpp:244 / crashProc]
Tue Nov 05 18:52:00 (INFO ): [racer] Crash detected - attempting to recover some data before displaying the crash dialog [main.cpp:245 / crashProc]
Tue Nov 05 18:52:06 (FATAL): [racer] Exception 0xC0000005, flags 0, Address 0x0058BF43
(this dialog text is stored in QLOG.txt)

....wired...

 

[Alex Forbin]

hmm...i have a strange green color after the change to 08b...
same car, shader, track...
rc08


and rc08b

....wired...

It looks like a clamping issue at the low end in the shader. It's probably just temporary since it looks like Ruud is experimenting right now with skies and water.

Alex Forbin

 

[Alexander Knoll]

ah..ok..THX Alex

 

[QuadCoreMax]

By default, on ATI cards, Racer doesn't work correctly, all kinds of flickerings & strange stuff happening (bloom shaders I suspect) when playing on 3 screens.

Somehow, I'm disappointed, the Qlog error list is too long to expose it here.
If next versions could just listen & dynamically set racer.ini accordingly, that would be great.

I bet a lot of people are scared seeing all those issues & uninstall the whole sim as fast as they have install it...

P.S.: Wouldn't be possible to expose/port C++ Racer code into Unity ? The fact is there's a tremendous amount of devs with custom packages taking care of all aspects (graphics/physics/shaders/animations/GUI/TODs...) of a game, so it would be 1000% faster for you to maintain...

 

[Cosmo°]

Thanks for the explanations Ruud, I'll go through them and see what's what.

The RC8b update makes things worse for me - as soon as a vehicle goes into the reboundstop, forces explode and Racer crashes with wheel force NaN given as the reason. Compared to vanilla RC8, where the vehicle behavior was odd but could be recovered with a reset.
I'm welcoming the hard limits for the suspension travel, but of course we shouldn't have to get rid of bump and reboundstop spring and damping to make that work, as those are widely used setup devices in their own right.

The airtime pitch effect is exactly how I "measured" the behavior as well, either going over a ramp or simply driving off the edge of a test map - vehicles would flip forwards or backwards at varying speeds, clearly unrelated to the CoG or CoP (aero) positions. This would go away when bump/reboundstop damping was zeroed out.

Hm, while typing this I thought about what I posted in February, regarding the "aerial pitch bug". I made the observation that if there was an offset between the sprung mass centre of gravity and the total mass centre of gravity, a pitching behavior with its severity being proportional to the length of the offset occured:

http://www.racedepartment.com/forum/threads/racer-v0-9-0-rc5-released.59820/page-11#post-1358165

Now, trying the same experiment in RC8, changing the unsprung masses (to shift the total mass CoG) doesn't produce the same responses anymore, the pitching occurs regardless of whether an offset > 0 exists. Meanwhile, RC8b crashes as per the description in the beginning of this post.

 

[William Geuze]

P.S.: Wouldn't be possible to expose/port C++ Racer code into Unity ? The fact is there's a tremendous amount of devs with custom packages taking care of all aspects (graphics/physics/shaders/animations/GUI/TODs...) of a game, so it would be 1000% faster for you to maintain...

Keep on dreaming

 

[boomer541]

Bugs! They are still with us.
sky_v.cg and/or sky_f.cg in the data\renderer\shaders folder has a problem on my Surfaces and sounds track the sky hills hava bright green color and changing the sky shader in the track folder to the day_night_v or f.cg's fixed the problem.

Also,
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.

There were a couple of the bugs on the Bug list in ver 0906 thread that were fixed and I thank Ruud for those but it's the little ones that some people dismiss that irritate like hell and should have been fixed in the last ver.

A good bug free version is what I think we would all like to see BEFORE Ruud adds any more 'features"!!

 

[Mr Whippy]

The sky bugs are because the sky is a work in progress it seems.

The new sky model is kinda squished in alongside the old sky model, so we have two models coming up with values for how extinction (the fog in the scene objects) looks.

Really all the old stuff needs stripping out and this new sky driving the entire scene lighting.

This new sky looks to have automatic clouds rendering, and animation, and when you add clouds the lighting values it generates to light the scene change (as they do IRL)... all very nice if it's implemented.

Though I still think real sky images look way better for Racing games. Skies are by definition so varied even in the variables that would drive a simulated one, that you need a full-sky texture to define those properties. Ergo you may as well just use an image to begin with

Dave

 

[Alex Forbin]

The sky bugs are because the sky is a work in progress it seems.

The new sky model is kinda squished in alongside the old sky model, so we have two models coming up with values for how extinction (the fog in the scene objects) looks.

Really all the old stuff needs stripping out and this new sky driving the entire scene lighting.

This new sky looks to have automatic clouds rendering, and animation, and when you add clouds the lighting values it generates to light the scene change (as they do IRL)... all very nice if it's implemented.

Though I still think real sky images look way better for Racing games. Skies are by definition so varied even in the variables that would drive a simulated one, that you need a full-sky texture to define those properties. Ergo you may as well just use an image to begin with

Dave

What you're seeing is probably "Silverlining" from Sundog Software. You will see some entries at the end of Racer.ini about Triton SDK, this is another dev kit from the same group for water development. The examples are impressive, if this is indeed what Ruud is considering I think it would be great since it would integrate the graphics with a really nice and fully developed system that appears to use actual data as much as possible.
You can read more here....
http://sundog-soft.com/sds/features/ocean-and-water-rendering-with-triton/

Ruud, I hope I'm not letting the cat out of the bag.

Alex Forbin

 

[Mr Whippy]

I think the sky is by someone else, it's linked to in the atmosphere.cg file, I posted a link a page back iirc.
The clouds don't look as good as that one above, they are not volumetric/particle based from what I can tell, they just look like pasted onto a dome types.

But maybe the water/sea stuff is indeed from them for some jobs. I noticed Cruden are now doing a powerboat simulator so they need nice sea rendering techniques!


It'll be nice to get that reflect shader working then we can have nice lakes and water puddles on our roads etc too. Iirc it was added a few Racer versions back but didn't work right.

I'm kinda hoping Ruud can find the time to remove the sun from envmap rendering while he re-works this sky system then we can finally get proper energy conserving materials working without compromise

Back to specular to simulate the sun in reflections!

Dave

 

[Alex Forbin]

Does anyone still have a copy of the first script example that let us shoot a ball from the front of our car ala Viper Racing?

Alex Forbin

 

[latrippa91]

there is someone who has an ATI graphics card ? If yes there is a fix to get rc8 working with ATI ? thanks

 

[QuadCoreMax]

You're not alone latrippa...

Just coming back to my ideas, there's an Infinite # of reasons to create a Racer Physics UnityPackage + Racer Editor UnityPackage :

- no more worries with all the graphics
- no more worries with animations (all types)
- no more worries with scripting possibilities
- no more worries with multi platforms (Linux, PC, Mac...)
...

We would benefit of :

- being able to build/generate Racer exec with all the stuff we ONLY want/need.
- an INFINITE ways of combining ALL the best codes/packages now available in Unity (shaders, gameplay...)
- long-term/SUSTAINABLE coding possibilities (Unity JS, C#, Boo...)
...

Giving a try wouldn't hurt anyone. Same could be done probably with UDK or CE3, still they all use a custom 3D format, so that's 1 of the major reasons, Unity uses obj, fbx, vrml ....which are all "directly" exportable from our different 3D packages & we can handle them really easily !

I see death in Racer, if it doesn't right now evolve more with OTHERS (shaders experts, hardcore programmers, visionaries...), I'm tired of being here, EVERYBODY speaks ALONE & no1 really understands / com-prehends why we still struggling of getting something perfect. I know why Ruud does what he does & why all this ILLUSION of getting something "better" is going on & not actually succeeding.