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.

 

[Stereo]

Someone left half a wheel in my garage... (I think that's the blur model being drawn at 0,0,0)

 

[luthobu]

I noticed you have the same problem, the dreaded red/blue stub image.

find the code in the track.shd for garage1 and replace this:

shader_roll_shutter_rails~vf_standard
{
  layer0
  {
    map=q_generated
  }
}

with this..

shader_roll_shutter_rails~vf_standard
{
  layer0
  {
    map=roll_shutter.tga
  }
}

 

[DavidI]

The default garage isn't ideal for all vehicles, e.g. GraveDigger monster truck, it's just too large. I only see the wheels & undercarriage. I suspect the buses & trucks that have been popular before would have similar issues.
Maybe the models could be scaled with a 'preview_scale=0.5' in car.ini?
Or maybe specify a garage to be used in car.ini? so car maker can make & supply a custom garage with vehicles, or have their own team themed garage.

 

[luthobu]

It is pretty easy to make your own garage. Took me less than 10min.
Not an improvement, neither a replacement, just wanted to see how
it works. Now I just wish I could get rid of that overbright..

 

[DavidI]

I like option 1 imho, then it works with default garage easily, and other custom sheds without stuffing around. Option 2 leads to complications & larger downloads.

 

[boomer541]

Qlog problems:
racer/3988] DTexture:EnableMipmap() called after creation (data/images/bestline.tga)

racer/2564] d3LoadTextureMap(); can't load 'data/tracks/garage1/q_generated'; creating red/blue stub image
racer/2564] Image 'q_generated' not found for shader skin0/data/tracks/garage1/roll_shutter_rails
q_generated is not an image! noted luthbo's comment!

Mirrors on car too bright, compare with large rectangular mirror!

Text too small and can't be adjusted! See attachment, I modified the slides and overlay image.

Hay bale moveable hit and it bounced of rail then started bouncing, each bounce higher than last, now headed for mars!

From racer.ini:
; Move CG to match nullpoint? Needed to fix CG problems (set to 1). Default=1; 0 is for backward compatibility.
I'm confused! Aren't cars made with all parts of the car referenced to an x=0,y=0,z=0 point which is the null point? With move_cg=1 parts such as wipers, brake calipers, gauge needles and suspension parts are no longer located properly. The "Suspensions" page on racer.nl states that attachment points are relative to the nullpoint, 0,0,0, not always = to cog. So if cog is moved to the nullpoint everything referenced to the cog is therefore placed wrong. Also see the "nullpoints in racer" page.
I think some one didn't do thier homework be cause I will have to use "move_cg=0" for all cars in order to have the parts located correctly! Also would it be better to have the move_cg in the car.ini folder so that if needed for somthing I don't understand it would not affect other cars?

Will try the "offset" code metioned in a prvious post and see what that does.

After selecting a car the track mini map doesn't appear, reload and it's there.

 

[Cosmo°]

First of all I'm glad that the CoG offset bug has finally been tackled - it's taken several years of continued reporting of the issue to get a working solution. I have to say though that it's not quite clear what's been done now, behind the scenes. So these dependency issues (cameras, models...) are a bit surprising since there's no real explanation given other than the racer.ini.move_cg setting ...and that shouldn't even exist in the first place since we're talking about a bug here, not an optional feature.

Perhaps the side effects of the bugfix are just bugs themselves. It would be nice to hear from Ruud about this, what's actually changed now and why it messes up things that shouldn't depend on the CoG location.



The name "move_cg" is a little unfortunate perhaps, as it implies something you wouldn't want to do if you set your vehicles' properly already. However, it seems to do the right thing - which is to remove the offset forces that occured before - and not modify the CoG location of of your vehicle.

Reading the comments so far, I think many of you didn't notice the problems with CoG offsets before. At least that would explain why some are sceptical of the bugfix It's easy to check for yourself though, just use a previous beta to load a car where you changed the cg.offset in y or z direction by 0.5m or more (to amplify the effect, it also exists with typical offsets that are a bit smaller). What happens is that the vehicle will either shake sideways and flip right after spawning, or it will start doing that once you move around a bit, turn even slowly, etc. Try the same vehicle with zero offsets to get stable behavior. For demonstration purposes it's enough to just alter the offset, but for testing the bug properly you'd want to shift the suspension positions around to keep the weight distribution identical of course.

The documentation links that Boomer posted all suggest authors should keep CoG and NP in the same place, but rarely anybody did that over all the years. If you positioned the body mesh accordingly though, there would be no changes in the camera positions and so on now (again, quick test is all that's needed).

What I'm trying to say is don't let that little bit of inconvenience make you drop the bugfix. Having the CoG properly defined is essential, not optional.

 

[Splashonda]

Just a quickie question that's not entirely related to 0826. If in previous versions I have CoG set to 0 on all axles (x,y,z), the car handling problem will be corrected, right?

 

[Cosmo°]

Ruud will have to say whether there was absolutely no influence at all, but from testing alone you're right. Zero cg.offset values create zero leverage for the buggy forces, so no ill effect was apparent and you don't have to adjust the vehicle now.

 

[EngineOfDarkness]

Ruud will have to say whether there was absolutely no influence at all, but from testing alone you're right. Zero cg.offset values create zero leverage for the buggy forces, so no ill effect was apparent and you don't have to adjust the vehicle now.

So that basically means that you can and should set the CoG by positioning the model correct before exporting, instead of using the old cog_offset.

And for already existing cars one could use modelers "Center to origin" and then "Translate" to move the Nullpoint and the CoG I guess (or import it into a programm, though I guess the modeler approach would be quicker).

Better than having weird forces act upon the car.

 

[Cosmo°]

So that basically means that you can and should set the CoG by positioning the model correct before exporting, instead of using the old cog_offset.

That's the best way indeed, but cg.offset has a reason to exist as well and with the bugfix (ignoring the current side effects) you can use it without unwanted forces acting on the vehicle.

A case where you might want to use an offset for the cg is when you have several versions of the same base vehicle. Let's say you're using a batch file that changes the cg.offset in car.ini to simulate adding/moving ballast on a race car. You wouldn't want to have ten different instances of the practically the same body mesh in the folder, for every CoG position.

So it makes sense to have a working cg.offset, but it's not necessarily "good style" to rely on it if you really don't need it for a single setup of the vehicle.

And for already existing cars one could use modelers "Center to origin" and then "Translate" to move the Nullpoint and the CoG I guess (or import it into a programm, though I guess the modeler approach would be quicker).

Better than having weird forces act upon the car.

Doing all of that would be nice and clean, but actually with move_cg=1, you don't have to touch the old offset settings, nor the body mesh. It's just the cameras and generic models that are somehow repositioned currently, but I'd wait for a reply from Ruud to hear what he has to say about it - maybe it can be fixed easily from his side.

 

[Stereo]

I think the new move_cg is intended to translate the cg and the nullpoint into the same spot on the model, so you don't have to get it right in the modeling program (or adjust it through offset)

Anyway, I think the visual models should be separated from cg/nullpoint as much as possible - though I'm not sure what the best structure to handle that is. Having to move all the cameras and generic models when the cg moves doesn't seem optimal.

 

[luthobu]

Racer 0826 - SM2 compatible patch

Here is the the optimized racer.ini, includes 2 SM2 compatible cg files for
compabilitiy with more low-level GPUs. Get the racer0826_SM2_patch.7z

 

[Mr Whippy]

That whole CofG thing is confusing.

I'll say best to make good content to start with, and that means common null-points and properly setup models pre-export to get the CofG position right, susp offsets correct etc.

BUT, I don't like the fact that the feature (CofG offset), doesn't work properly.

I'm struggling to understand if it now does work properly or not?! If it does, then shouldn't all content just work right now?

Why do we need a flag in racer.ini if the problem is fixed?

As much as it's wrong to do it, we SHOULD be able to set the null point on the floor at the front of the car, and do all our positions from that location for CofG, flares, wheels, suspension, etc etc, and the car work EXACTLY the same as if we put the CofG in the right place and did all the locations properly.
Using offsets for the models over the top just sounds confusing and dangerous and yet another mine-field for the future.

If this is the case (ie, it's a fudge fix), I'd prefer v0.9 to simply remove the CofG offset feature and model offset features, and for authors to make the content right.
This possibly dodgy fix has the potential to just screw up a whole load of content in another few years time. We need to get away from this methodology of just making things work for now because so many authors will use these dodgy methods to make content.

Lets do it right or not at all.

(assuming this is a dodgy fix, because theoretically if it was fixed there is NO need for a flag anywhere, content would just work better)

Dave

 

[Alex Forbin]

I've got to admit, I find the whole thing confusing. Apparently the wheels/steering wheel/lights are moved with the model but cameras/wipers and a few others are not (yet).
I think after 10 years of development, Racer is bound to be a bit of a monster now in regard to physics debugging. If it will eliminate future errors I'm willing to bite the bullet and reposition the cars to eliminate the CofG offset (most need updating anyway).

Collision hulls seem to be broken.

Alex Forbin

 

[luthobu]

hmm...all generic objects are on the wrong place....

Wow.. I was looking at that shot this morning, and it hit me how
surreal it is.. the fog, the "flying" parts, and even the skidmarks
go the wrong way.. a fantastic shot really..

 

[boomer541]

Use "show carpoints" in the console to see where the cog and np are located as well as the suspension locations.

When making a car all vertices are referenced to x=0,y=0,z=0 and that is the null point the cog is dependant upon the weight of components of the car and can be calculated and then inserted into car.ini. That's the way it's been done!

Are we saying that we have to calculate the cog and then make the car vertices referenced to that point. Wheels, gauge needles, and the other generic objects still need to be referenced to 0,0,0. Damn near impossible to make a car that way!

How about those flying hay bales? Also the skid marks aren't very good and need a bit of tweaking to make look good.

 

[DavidI]

Skid marks also need to take into account the wheel's actual width, eg current skidmarks, sand, grass & smoke all look comical with GraveDigger's wide wheels.

Along another tack, what currently does Newton do in Racer? I have difficulty using real world values when trying to get a decent setup for GraveDigger, the forces are too large, I have to modify the caps in racer.ini. Do we need these caps nowadays? Could Newton be used for suspension physics if not already, to allow heavy vehicles to work?

And can Newton help 4WD simulation somehow?

 

[Ruud]

hmm...so you have to moove the body model to the right place.....to use x/y/z = 0 to get the right waight distribution and CoG high?.....hmm...will see to night if i can get my ass up to test it^^

THX

No, actually you should use move_cg=1 (which is physically more correct; otherwise your car won't rotate around the CG.xyz but the nullpoint instead, which is not right!).
See the attached car example; it has the nullpoint (white) between the rear tires, but the CG somewhere in the middle (blue). With move_cg=0, the chassis will rotate around the rear tires. With move_cg=1 (correct) it rotates around the CG again.

Funny that the generic models don't work; perhaps something with use_vbo=0 or 1? I've tested it with the Baja and there it worked (although I did have to tweak which models were offset with the CG and which weren't). Do you have a link to that car where you have the problem?

 

[Ruud]

So...how come the lighting is different in the car selection screen to the "garage" track? (clicky for bigger)


Also did a SUPER quick mockup of the car selection screen. IMHO we don't need a list as well as the buttons down the bottom.


I might do a quick mockup of the entire menu system...Though the UI elements might need to be updated (to something like what Some1 suggested? idk what benefits Qt actually has) I believe the UI elements are too static and clunky atm.

The lighting/shadowing in the garage does not work yet. Something with the CSM camera probably.