Racer v0.8.26 released!

[Ruud]

The usual, but 2 big things: a garage when selecting the car (getting rid of the white cars) and an important bugfix if the CG is not at the nullpoint.

Get it at http://www.racer.nl/download/racer0.8.26.zip (100Mb, due to the extra garage track!)
CG movement patch (only the racer.exe) is at http://www.racer.nl/download/racer0826b.zip (1.5Mb).

The garage is still a rough preview but you can plugin your own garage1 track (I might add the possibility of multiple garages). The CG bugfix is optional; in racer.ini find 'move_cg': 1 is the new default, 0 is the situation as from v0.8.25.

Changes:
v0.8.26 (10-12-10)
-----------------
- Skidmarks tweaked to be more opaque.
- Some bumpshaders modified the normal map's alpha, giving funny reflectiveness issues.
Resolved using an extra 'common/utils.cg' file with UnpackNormal() and used in all bump shaders.
- Best line tweaked; fades out near the car, green lines are faded. Less intrusive.
- Added Logitech G25 wheel preset file (thanks to QuadCoreMax)
- Modeler can now export a template shader (.shd) file for a loaded model
- Pressing P in replay a few times doesn't mess up the volume (on/off) anymore
- Non-Cg version still created mirror and live track FBO's
- Particle system would crash with some car/track combinations. Seems related to culled single-poly fences.
The road is culled and single-poly, and really hitting the track seems a problem for Newton.
- Same change for the particle system done to the exhausts (arrays instead of std:vector)
- Not all collide polygons were used for Newton's collision tree. Rebuild trackcollision.bin
- Car selection screen now loads 'garage1' track as the environment. Pitpos0 is the car location.
- Tracked spline selection now accepts Shift-[,] for multi-select (local grip editing)
- Default font made a bit smaller, since everyone's running at least 1024x768 anyway.
- The Ctrl-9 screen could show bad load balance when the nullpoint was outside
of the front and rear wheel susp<n> locations (extreme CG movement tests).
- CG translation bugfix in the physics; an important one! Use move_cg=1 in racer.ini.
- Ghost car playback didn't work correctly.

 

[Some1]

Shadowmapping settings used in the videos:
racer.ini:

shadowmapping
  {
    ; Enable shadow mapping? If enabled, changes the Cg shader directory to
    ; data/renderer/shaders_hdr_csm (!) instead of data/renderer/shaders_hdr
    enable=1
    ; debug mode (paints splits)
    debug=0
    ; size of the debug polygons rendered
    dbgsize=128
    ; blur the shadowmap (slow) 
    blur=0
    ; Profiles for different camera types
    profile0
    {
      ; outside car
      ; nr of splits used, each split takes one extra render loop (3 should be enough)
      splits=2
      ; texture resolution; MUST match that in data/renderer/common/constants.cg!
      mapsize=1024
      ; split distances 0 - 3, each distance higher than the previous one; now in data/renderer/common/constants.cg? (not true probably)
      splitdist0=10
      splitdist1=500
      splitdist2=75
      splitdist3=500
      ; the amount of frames to skip to increase performance
      splitrenderjump0=0
      splitrenderjump1=0
      splitrenderjump2=15
      splitrenderjump3=30
      ; offset the framecount for jumping frames
      splitrenderoffset0=0
      splitrenderoffset1=0
      splitrenderoffset2=0
      splitrenderoffset3=7
      ; debug mode (paints splits)
      debug=0
      ; size of the debug polygons rendered
      dbgsize=128
    }
    profile1
    {
      ; inside car
      ; nr of splits used, each split takes one extra render loop (3 should be enough)
      splits=2
      ; texture resolution; MUST match that in data/renderer/common/constants.cg!
      mapsize=1024   
      ; split distances 0 - 3, each distance higher than the previous one; now in data/renderer/common/constants.cg? (not true probably)
      splitdist0=10
      splitdist1=500
      splitdist2=75
      splitdist3=500
      ; the amount of frames to skip to increase performance
      splitrenderjump0=0
      splitrenderjump1=0
      splitrenderjump2=15
      splitrenderjump3=30
      ; offset the framecount for jumping frames
      splitrenderoffset0=0
      splitrenderoffset1=0
      splitrenderoffset2=0
      splitrenderoffset3=0
      ; debug mode (paints splits)
      debug=0
      ; size of the debug polygons rendered
      dbgsize=128
    }
    mapsize=1024
    shadowintensity=0
  }

const float smCor[SM_MAX_SPLITS]={0.0001, 0.00075, 0.005, 0.005};

 

[Alex Forbin]

Wow, nice article. It looks like it has solutions to all of the shadow problems.
Great find.

Alex Forbin

 

[Some1]

The first time it also loads all cars...

Holy cow!

If you gave 10gb worth of cars, it will probably crash trying to fit them all in memory.
How about just loading on demand and with a progress bar or loading indicator.

Modern gamnes take advantage of the multi-core setups and do loading of game data in separate thread. So, many games have animated loading screens and almost no stuttering while loading data, everything seems so smooth. Almost everything is loaded in separate threads and/or streamed from disk...

 

[EngineOfDarkness]

On those damper curves; they seem pretty symmetrical bump/rebound. I've seen sportscar damper curves (actual data) where the rebound is about 5x as stiff as bump. Good for not dropping into potholes perhaps with stiff springs.

These are loosely based on the PDF Files I linked in the Topic there. It's something to start off I guess.

The first time it also loads all cars, so that might take a while too.

I guess I should avoid the select car screen at all costs for now (having about 700+ cars here, ranging from 0.50 Final content to todays content).

I'm too much of a collector I guess.

 

[Mr Whippy]

Good videos there Some1

I don't dispute there are things wrong with the shadows, but the interior/exterior (how they were defined is beyond me though) cameras half resolution behind the car thing does seem to have gone.

But what you show is clearly another issue too


The shadow split following the sun position makes sense (ie, the box is drawn sun relative, as that is the shadow source), but it looks like the reference point it picks for the car centre is the camera itself in the SMD camera case, and the 2nd video, it looks like the sun aims too high at sunset!?

Hmmm

Sure they are relatively easy fixes, just the targeting that seems the issue?!


Good link to the MS resource btw!

My biggest single bug-bear right now is that the first split is so big, not allowing nice sharp shadows, which may also mean the smCor values are not ideal and so tops of tyres are remaining lit under cars wheel arches... just looks really bad unfortunately


Things are getting better, and can only get better still though, all good stuff

Dave

 

[Ruud]

Holy cow!

If you gave 10gb worth of cars, it will probably crash trying to fit them all in memory.
How about just loading on demand and with a progress bar or loading indicator.

Modern gamnes take advantage of the multi-core setups and do loading of game data in separate thread. So, many games have animated loading screens and almost no stuttering while loading data, everything seems so smooth. Almost everything is loaded in separate threads and/or streamed from disk...

Not to worry; it only loads the car.ini files (which still takes a while) to get at the full name. I've thought a lot about multithreading the loading, however, it seems you need quite a bit of syncing as you would use OpenGL from 2 threads; one painting with textures, the other loading new textures. Might give some racing issues.

 

[Ruud]

Good videos there Some1

I don't dispute there are things wrong with the shadows, but the interior/exterior (how they were defined is beyond me though) cameras half resolution behind the car thing does seem to have gone.

But what you show is clearly another issue too


The shadow split following the sun position makes sense (ie, the box is drawn sun relative, as that is the shadow source), but it looks like the reference point it picks for the car centre is the camera itself in the SMD camera case, and the 2nd video, it looks like the sun aims too high at sunset!?

...Sure they are relatively easy fixes, just the targeting that seems the issue?!

My biggest single bug-bear right now is that the first split is so big, not allowing nice sharp shadows, which may also mean the smCor values are not ideal and so tops of tyres are remaining lit under cars wheel arches... just looks really bad unfortunately

I played around with shadowmapping this afternoon; now using 10m for the 1st split, then 100, then 1000m. Perhaps for really large tracks the last part should be blended away (as the first 2 blends blend into eachother, the missing shadows beyond 1000m might be faded out, although it's a bit slower again). I still need to tune smCor[], but it sure looks nice.
I also tried to understand Mitch's focusing methods; INCAR and NOCAR views get the camera heading shift (to move the shadowmap more in front of the camera) plus profile1. Other cameras (moving around the car) keep the car center focused and profile0. Director cameras are a bit of a nuisance but now seem generally ok. I added some code in shadowmapping.cg to visualize the 3 shadow splits:

float ProcessShadow(float4 shadowCoord, sampler2D shadowTex, float z, int smSplits, const int index,const float corFactor)
{
if(index==0)return 0.2f; else if(index==1)return 0.9f; else return 0.0f; // DEV
...

That worked quite nicely. With the 10m and 1024 mapsize, the shadows in the F458 are quite nice! smCor might still be a problem with those wheel arches. In the end it will always be a trade-off.

I also added some controller functionality; no longer does Racer crash if your G25 isn't plugged in. And there are now 3 profiles you can select in the controller setup screen. Still, naming those should probably be done. Being able to add loads of profiles (such as in rFactor) isn't really necessary I think; with 3 profiles you have a mouse setup, a wheel setup and possibly a 3rd setup. These are data/controls/profile1.ini upto profile3.ini (so saving to a non-default.ini is now also possible).

The shadow sun aim at sunset btw is perhaps not too important; near sunset, with long shadows, it should fade out shadows anyway to avoid lots of aliasing artifacts. And Cosmo, thanks for those videos, was very helpful.

 

[Mr Whippy]

I've used 4 splits here, no blurring (but you can run it if you like) and these distances

splitdist0=10
splitdist1=45
splitdist2=200
splitdist3=850

That seems to work nicely here... ~ 4.5x scaling gradient feels really good... some acne on the 45>200m split, but it's rare where it appears.

The long distance split is nice on my bigger tracks as some shadows are big and really shade out some areas... 600m might be ok with a blended last split though, since it'd soften the edge which is so obvious right now if the shadows end too soon!

For interiors I found this works ok:

splitdist0=5
splitdist1=30
splitdist2=150
splitdist3=850

a steeper scaling gradient (~6x), but you are generally lower, see less and notice less from interior cameras

splitrenderjump0=0
splitrenderjump1=0
splitrenderjump2=15
splitrenderjump3=30

splitrenderoffset0=0
splitrenderoffset1=0
splitrenderoffset2=5
splitrenderoffset3=10

5m seems to cover an interior on any car I've tried really nicely, and then some render jumps... much less noticeable from interior view... unlike while your car in a replay camera driving away at a distance can get a really jumpy shadow and look pants.



Is there any way to clarify when each camera profile is used?

Profile0 is for all cameras, except profile1 for interior views (ie, set in car.ini camera setups to use model=1?)

Any other logic might be questionable there. Mitch's moving the shadow map doesn't seem sensible if the 1st split is 10m, and we have a blend too between split0 and 1, so we are almost having the blend move over the car whichever way the shadow map moves.

Surely it's best to just have the two profiles and no fancy trickery? One for interiors where you need good sharpness around the interior, and one for outside that follows the car really tidily (ie, just stays 10m box perfectly around the cars cofg (=np )?


Also good to hear on the controller profiles! That will be really helpful here if the wheel isn't plugged in and I just want mouse controls etc

Dave

 

[MitchVL]

No, not really... the standard camera seems to be okay, but the SMD camera, which is mostly used for chase and cockpit, is still buggy.
The default shadow mapping settings hide the bug, but it is still there.

Here are two videos illustrating the problem.
I've disabled shadow blur and shadow split blending. I'm using 2 splits 'splitdist0=10' and 'splitdist1=500' and shadow map size of 1024, to better illustrate the problem. On the videos, you see the first split is clean and nice, the second one has intentional severe aliasing (commonly called 'shadow acne') artifacts (from the smCor values), to make the splits more visible.

The first video shows how the first shadow split is not correctly aligned around the car center, making the car run out of the first split as it drives around in circle. Using standard camera, the first split is nicely in the center.


The second video shows how the shadow split moves with the sun, and look closely at the end of the video, the first split starts to float away from the car, again making the car appear in bad shadows.



I would also like to see the shadow acne minimized or eliminated, so we could have great looking self-shadows etc.
Please check out this link about common shadow mapping problems and solutions: http://msdn.microsoft.com/en-us/library/ee416324(v=vs.85).aspx

Shadow mapping in Racer is good, but not perfect!

The CSM focus behaviour of the first video is the one for inside camera views, with camera heading and focus on the camera if i can see it correctly. Is that camera defined as inside view ?
It's normal that the car goes in and out of the smallest split because it's a rotating square ...


The CSM camera MUST follow the sun's rotation because you will get flickering pixels otherwise. Now all pixels are dead still when the shadowcaster is static, that's how you want it to be.


In the second video, the split moves away because the focus point is not on the ground but on the car, so maybe 0.5m above the ground. So when the sun lowers, the projection on the ground will look like it is moving away from the car.

I can't see any bugs

 

[Mr Whippy]

Mitch, the camera heading/focus thing is probably what is broken then.

How do you determine if it's an internal camera?

car.ini camera.model=1 flag?

Imo, that is the only nice way to determine an internal or external camera...?!

Surely, also, if it's an internal camera, you DON'T want that to happen. In my case, a 5m split for internal cameras might mean the back of the cockpit is projecting low quality shadows forwards (sun behind you), because of the blends between splits!?

I must admit I'm struggling to get the logic of the camera heading pushing the split centre around. Even for internal cameras it's risky with a nice sharp small 1st split!

Any chance we can have a flag to disable this, or a way to do so, simply for testing purposes? If it proves useful, great, but I'm struggling here so far, but it's hard to test without it to check if problems go away

Dave

 

[Ruud]

The 0.5m explains the floating away then. I did move around the 1st split so that it centers around the car more (for non-interior cams); doing so will make sure that any shadow near to the car is crisp. You don't really want the car shadow to move into the 2nd split and the resolution change becoming visible.

 

[Some1]

The CSM focus behaviour of the first video is the one for inside camera views, with camera heading and focus on the camera if i can see it correctly. Is that camera defined as inside view ?
It's normal that the car goes in and out of the smallest split because it's a rotating square ..

No, it wasn't defined as an inside view (unless there are some new settings for cameras I'm not aware of).
Anyway, what I forgot to mention was that the shadow splits in the SMD cameras followed the camera, not the car. As you moved away from the car with KEYPAD_1 or KEYPAD_3, the shadow splits followed the camera and the car was left into the low res shadows.

There certainly are differences in shadow rendering between SMD and standard cameras!

 

[boomer541]

Fantabulous, Ruud!

The patch fixes the cog issue very nicely, thank you! I'm quite happy with ver 0.0826!

Now about hose flying hay bales...

 

[Ruud]

Fantabulous, Ruud!

The patch fixes the cog issue very nicely, thank you! I'm quite happy with ver 0.0826!

Now about hose flying hay bales...

Where do you get flying haybales?

@Cosmo: in your last sentence you probably mean SMD cams? (cameras on springs). The fixed ones (follow pitch/roll/yaw) are the other kind.

 

[Some1]

@Cosmo: in your last sentence you probably mean SMD cams? (cameras on springs). The fixed ones (follow pitch/roll/yaw) are the other kind.

Indeed, I meant SMD cameras... cameras on springs. Sorry about that.
We'd use the SMD cameras for chase and incar.

I read a little about multithreading texture loading in an OpenGL app, it is not so trivial after all. Basically, from the main thread, one needs to create two OGL contexts - one for rendering, one for texture loading (that is, sending the texture data to OGL?), and also on Windows wglShareLists needs to be used to share data between these contexts. Obviously this is too much work to make an existing app, such as Racer, multithreaded like that...

 

[Mr Whippy]

Can we have clarification on the csm profiles?

Profile 0 all the time, relative to the camera, for all cameras, SMD, track, outside car fixed etc.

Profile 1 only used on internal car cameras, defined by model=1 in the camera definition?


Dave

 

[boomer541]

I changed the haybales to individual movables on my Watkins Glenn track and when hitting them and they bounce against the guardrail they bounce off the rail and hit the ground and bounce about three times. Each bounce gets higher and higher until it disappears.

The first variable is set = 1000 and the inertia is set = 0.5 0.5 0.5.

There are more important items to work on so I'll just keep fiddling with them until I get it fixed or determine a cause.

I do Thank you, Ruud for all you have done to make racer so damn good!

 

[Ruud]

Can we have clarification on the csm profiles?

Profile 0 all the time, relative to the camera, for all cameras, SMD, track, outside car fixed etc.

Profile 1 only used on internal car cameras, defined by model=1 in the camera definition?


Dave

Profile 0 by default. Profile 1 for close-up cameras: model=1 (incar specific 3D model) or model=2 (no model). Note that for model=2 it doesn't really make sense since nothing's showing anyway.

 

[Ruud]

I changed the haybales to individual movables on my Watkins Glenn track and when hitting them and they bounce against the guardrail they bounce off the rail and hit the ground and bounce about three times. Each bounce gets higher and higher until it disappears.

The first variable is set = 1000 and the inertia is set = 0.5 0.5 0.5.

There are more important items to work on so I'll just keep fiddling with them until I get it fixed or determine a cause.

I do Thank you, Ruud for all you have done to make racer so damn good!

You're welcome.
And for the haybales; the inertia seems more to define ~1 kg of mass. Try increasing those, and a bit more along the longer axes.

 

[Mr Whippy]

What kind of bales are they?

Round, small squares, or big hesston/d1010 bales?


0.5 kg/m/s/s is a tiny amount as Ruud said. Try a basic inertia calculator for a cube or cylinder (wikipedia will have the calcs)

Rough weights I'd say.

Small square: straw small about 14kg, hay about 20kg
Round: straw about 150kg, hay about 200kg
D1010 and Hesston probably 220kg straw, and 350kg hay

Rough guesses from farming when younger, either knowing the loading on the tractor, or manually lifting hundreds of them haha!

Dave