Racer v0.8.26 released!

Ruud

RACER Developer
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.
 
When I pause the game, FPS drops from 40 or so to about 9..

By design. I sometimes pause Racer to do other things while leaving Racer running. To leave it eating 100% CPU while generating the same image over & over, and eating away CPU for other processes seems a waste of power.
 
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?

Skidmarks already use the wheel's width (from car.ini).
Newton is used for:
- pointmasses that get position/orientation with inertia effects; just the car chassis
- geometry collision

Wheels are modelled separately as doing suspension with springs coupled with joints is much more expensive, and everything was written out already. Given that a generic physics engine just integrates the whole lot, this would leave out things such as implicit integration, capping ARB forces and such. So Newton isn't really suited to the deeper sides of car integration. It just moves around the bodies, and takes care of collision resolving when 2 or more bodies hit eachother.
 
Set cog x,y,z to 0,0,0 with move_cg=1 and no body offset, the cog moved to the null point, generic objects in right place. But the cog is not where I want it.

Set body ofset to previous cog setting and the cog is at the null point, generics in right place, cog is not where I want it.

set cog to prvious settings to move the cog to where I want it and the generics are in wrong place.

Can't move the body.dof if it is in data.ar file so how does one set the cog where one wants it??????

I use the following reference pages to set the cog and suspensions, doesn't everyone? I don't think so!

References:
http://racer.nl/reference/nullpoint.htm
http://racer.nl/reference/carphys.htm
http://racer.nl/tutorial/newcar.htm
http://racer.nl/tutorial/development.htm
http://racer.nl/tutorial/car_coll.htm
http://racer.nl/tutorial/car_cameras.htm
http://racer.nl/tutorial/suspensions.htm
 
On the CG, there's a lot of confusion. Here's an outline of my goals (CG=center of gravity, NP=nullpoint):

The bug:
- when the nullpoint!=CG (cg.xyz!=0), the chassis would still rotate around the nullpoint, instead of the CG. That is physically incorrect. I have attached (again) the Fer312 CG example, where the nullpoint is far away (at the rear) compared to the CG. With move_cg=0, if you accelerate, it incorrectly pitches around the rear nullpoint. With move_cg=1, it pitches correctly around the middle CG.

The goals:
- Physics is a different expertise than modeling; therefore I do NOT want 3D modelers to need to move their 3D models to match physics rules. So, there is no need that the 3D model must be centred or somehow placed on some predefined location for it to be used inside Racer. In Racer, you can use the 3D model offset to match up the 3D model with the physics model. The 3D modeler will just create his car in Max or whatever, on a location he finds useful, and the car.ini author just relocates that 3D model using the body model offset.
This goal is readily present in Racer as it is.
- The CG should be placeable using car.ini's cg.xyz, relative to the nullpoint. The car should then rotate about this point.
The future:
- move_cg=1 is the way forward since that is physically correct. I've added the option for our own cars here since I didn't want to enforce it yet, if only to test the difference in a quick test on our high-end hardware to see how much difference it makes (our main car has a negative CG y offset). I've added a warning if you set move_cg=0, indicating you are introducing physics bugs that way.
- the car will behave a bit differently since the CG is now correctly used as the rotation point. If the CG was low, it might now feel a bit flatter (stabler?) but more testing needs to be done for statements like this. In any case, since the car rotates around a different point now if CG!=NP, car authors may need to tweak their suspension/ARB a bit to get the car to work nicely again.

Nothing-to-do-case:
- if you already had CG.xyz=0, the CG is already at the nullpoint and nothing changed. Offsets to the 3D models don't do anything to physics behavior anyway, except collision detection. It's CG vs NP that counts.

What Racer does internally:
- To fix the CG rotation point (the bug), Racer will move all car objects so that CG and NP overlap. In other words, Racer shifts all car-relative objects so that CG==NP. This means things like the car body, generic models, suspension points, wings.

What Racer paints with 'show carpoints':
- Actually, with move_cg=1, Racer effectively sets CG.xyz to 0 so that CG==NP. The nullpoint that is painted is really offset while painting to show you the offset of CG you defined in car.ini. Inside Racer however, CG==NP. It just offsets the painted NP to show what you originally defined in car.ini.

What car authors have to do:
- the bugfix should mean you don't have to change anything to your car.ini (no moving of all 3D models and such, no need to relocate the 3D model). But, physics-wise the car will now really rotate around the CG, so you may need to tweak the suspension to get it driving nicely again. If CG.xyz was already 0, it should remain ok.

Bugs remaining:
- Although I did test the CG offsetting on the Baja, it seems there are some unmoved car-relative objects still left. Amongst these are: generic models (the Y offset in the Baja seemed ok, but if I add a cg.z offset things indeed go wrong), camera positions.

I'll try and fix this today/tomorrow and will post a patch.
Hope this makes things clearer. There is NO need for car author to move around all their 3D models; but now that the CG is correctly being used as the rotation point, you may need to tweak your suspension to account for that new point (it used to be the nullpoint).
 

Attachments

  • fer312_cg.JPG
    fer312_cg.JPG
    57.4 KB · Views: 225
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!

Is it impossible?

Since v0.49 when I made my first car for Racer I set everything up so that the null point = CofG position.

I always thought that was best practice and is still shown as best practice on racer.nl docs?

CofG offset should always have been for small movements imo.


THAT said, I still think it should work right anyway. But imo, it's best to make the content right to start with. It's the FIRST thing I do when I set up my car. Find the CofG and bolt the whole lot to that location in 3DS Max. The centre of the world is the CofG for Racer :D

Dave
 
Just to refresh the subject of shadowmapping for Ruud: it seems the shadow splits are calculated from the Sun point-of-view, is this correct?
When driving into sunset/sunrise, the car shadow started to have very low res and was updated once every 3rd frame (just as I specified in racer.ini for the 3rd shadow split), so it seems the 3rd shadow split was used for the car, instead of the first one, which is usually the highest res.

BTW, Ruud, have you checked out this article, it has some insight about common shadowmapping problems and solutions: http://msdn.microsoft.com/en-us/library/ee416324(v=vs.85).aspx
 
Simple summation on CofG issue:

We need reference points. One for physics, one for gfx. Considering gfx author and physics author is good.

Having them both the same is very helpful though. NP works perfectly fine for that (as it has for Racers history so far)


CofG should just be an offset from the NP then, just like everything else in the car.ini, from susp offsets to light flares.

Why can't we just fix it so that the CofG offset works properly?



The fix we have here is like saying the susp3 position was always being drawn at the NP, so instead of making the offset work right, we now set the susp3=NP internally, and then use the original susp3.offset and apply it to EVERYTHING on the car... that way we get the car appearing correct.

That is the biggest fudgiest bodge fix of them all, ever! :(



I'm actually quite worried that this is meant to be a workable fix for the future that we should be excited about. It sounds confusing, complicated, potential for loads of errors/bugs and making content that goes wonky in future.
I'm assuming that we now have two reference points too, one for the physics guy (cofg), and one for the gfx guy (NP), so physics offsets in car.ini will be to the cofg, and visual offsets will be relative to the NP... so we have gone from one global reference point to TWO! Talk about simplification hehe.
Gfx author adds a wing at the back of the car, -0.5m in z axis. Physics author can't use that offset, he needs to use the cofg offset + the gfx authors offset to get the actual offset he needs to put the spoiler physics element in the right place... arghhhhh! And that's assuming the lazy gfx author hasn't exported the wing at world centre! Hehe.



I'll be avoiding this feature/capability like the plague I think. I just hope it doesn't break things that were not broken before!

I urge authors to do the right thing and still aim to have CG=NP, don't be lazy. The effort/complexity of setting this right from the start is about 0.0000000000001% of the effort needed to make a half decent car in the first place anyway!

Dave
 
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.

A bit additional to my post explaining the details on the CG fix, but to clarify a bit extra:
- the side effects are indeed bugs in themselves, rather than the original CG bugfix. The problem is that a lot of things are car relative, but some are relative to already translated car positions (such as the wipers) so it was done a bit too quickly. I'll post an update very quickly.
- move_cg was only optional to be able to quickly check the old result vs the new. I've added a warning if it's set to 0.
- as you stated, aiming for CG==NP in your car.ini is NOT the way to do things. That's why the nullpoint was invented in the first place; to be able to move the CG around without needing the 3D modeler. Since the CG now moves the whole car around though, a dynamic CG is less easy to make. Actually, your car gets offset with the CG offset, but I don't think that affects grid/pit position warps.

I'll fix up some of the documentation.
 
Dave,

Indeed, the advantage of the fix is that CG!=NP now works correctly. So the CG can be anywhere.

Quote: "Surely the way to fix the bug then, is to make it so that null point can be offset from CofG?"

That is the other way round; the NULLpoint isn't called that by chance; it is the point of origin for everything else. We offset the CG away from the nullpoint, we don't want to offset a nullpoint: that wouldn't be (0,0,0) then!

Indeed, ALL positions are offset to internally match up CG and NP again. That means flares, wipers, dials etc etc indeed. It does work nicely though in concept, since all is relative anyway. All your car.ini positions remain the same, since you're designing wrt to the nullpoint.

The problem doing it the other way around is halfly Newton-based; it does allow a non-NP center of gravity, but I tried that and the catch is that you need to translate-rotate-translateBack all your 3D models. Which doesn't fit too nicely with the current single matrix for each graphics object. The same amount of trouble would go into rotating each 3D model around its moved CG.

Just try it with the new version I'm about to release (just the exe). I still have to do dials, but the Baja now works correctly, wipers are fixed, generic models fixed, cameras also offset. Suspension positions already did (they need moving, since you're changing the position of the wheels relative to the CG).

You can ofcourse design your car with NP==CG, but generally nobody does and it doesn't make sense to need to offset the 3D model (requires access to 3D modeling skills at that point). A CG will be a bit dynamic in the future perhaps, when you add fuel load.

It's basically a very simple concept; if the CG moves from the NP, I can either try and get to work (lots of issues with graphics) or move all the car-relative stuff the other way (-CG). The 2nd method is actually a bit easier to implement, and is getting close to completion (I probably forgot some exotic models/things).
 
Hmmm ok, the newton stuff is a reasonable excuse the other way around :D

I'll let you off :D



How does this work with lowering the car CofG? Does that still work and mean that if I add another 5cm to the CofG offset that the car will sit the same in sim, but the CofG readout will be 5cm higher?

Is it best now then to assume the CofG offset is in effect the internal offset of the entire car to match NP=CG? So we are in essence unifying the CofG and NP to a common NP for the entire car...




Should we then ideally NOT be using a car.body offsets at first (ie, make sure these are zero)

I guess I need to tinker with this in practice to see what happens. I'm just worrying that authors might still do silly things.

Ie, car body offset could be used in one place to get a car in the right place, IF they use a different cars ini as a base, and then they might need to use those same offsets for the wipers, cameras and all that stuff, because the main body model is offset.


I know helping authors out is important, but the last thing we need is confusion as well... having NO offsets to the body models seems very logical since there is no good reason for it now... (maybe disable it for a bit while people get used to this change!?)



One last unrelated thing but I think would be nice while we are talking about making things nice for authors and physics people. Is there any chance we can define two models rather than one for the brake/wheel combo?
Right now we have to have the wheel model and brake model as one DOF, but that makes swapping brakes difficult (brakes are rather generic and could easily be copied/swapped among cars, or even default items etc, if we could specify them sperately)

Could also work for tyres longer term, but we won't go there yet :D

Dave
 
Thinking of a car with body offset 10m forward, CofG 15 backwards, and susp.z positions of -12 and -15m or something amusing.

It'd look right, but be ooohhh so wrong.




Hmmm on the CofG offset now not working...!

Surely it works in the up/down way as if you set it higher, then it IS higher realtive to the car body. So assuming the suspension moves too, then the whole car is kinda lower down in space, leaving the CofG higher?!


This could all get very confusing.

You need to draw a really good picture with lots of examples of how it all works, and a few cases of how you achieve certain things?


If CofG offset is now not really an offset though, maybe best to change it to CofG position, and then in future if we can offset it again, then you can use a new CofG offset?

Just to make it more obvious?

Dave
 
The CG offset IS the CG position relative to the nullpoint. Visually you only change the position of the CG; all the rest is taken care of by Racer. You're reading too much into it. To be able to rotate correctly, Racer moves the car objects around. Show carpoints still shows you the original nullpoint though. I have an almost completed version, just generic models without offsets might be tricked, need to crosscheck the F458's generic cockpit model vs the Baja suspension models.

BTW indeed, if you move the CG down (decrease Y), then the CG height goes down. Quite logical. :) The car visually doesn't sit any differently, but internally it has been moved up. But you don't see that in the endresult, cause it's all relative anyway. Just await the exe, here within 1 hour.
 
Arghhh...

OK...

I'm just trying to get a good explanation logic that makes sense.

The NP is set by gfx author initially, but when it gets to Racer it is reset by an offset to the CofG, so the new NP is then the CofG, simply set by an offset from the NP.


Just for clarity, is it best to refer to the NP as the CofG from now on when talking about cars "in" Racer, and then the NP as the 3d global 0,0,0 coords.

Using NP and CofG together seems to make little sense and just confuses explanation I think!?

Once we get a car in Racer the NP becomes the CofG so everything is then CofG relative :D




Sooooo, when we set susp.z positions, do we set those relative to the gfx NP to get them in the right place (so in the Ferrari example you posted, near 2.5m for susp0/1 and 0m for susp2/3), then use the CofG offset to push and pull the CofG around? That suddenly doesn't sound so easy because despite the fancy offset thing, we still need to reference relative to the gfx NP and then reference relative to the CofG for cameras, flares, and all that stuff!?


If I'm confused, then a newbie will be!


I'm sure in practice it might make a bit more sense, but that is exactly what I couldn't do when I first picked up Racer! WHAT? susp0/1 need to be at the back of my car to make it fwd!? Hehe!

Dave
 
No, everything is still NP relative. Internally things are moved so that CG==NP, but as far as you are concerned, you still define everything relative to the NP, including the CG. Susp.z positions are still relative to the NP; nothing changes, only internally.

It's always good practice to keep the NP close to the CG though, so that offsets make common sense. You CAN define the NP being somewhere high up there, but it doesn't help debugging your car. It used to also screw physics up; with move_cg it doesn't.
Close to getting that version out; where everything stays the same, it's just that the car now really rotates about the CG, not the NP.

To clarify that Fer312 image; that was bad design; indeed there I set the susp0/1.z to 2.5 and susp2/3 to ~0 meter, but as you indicate, that doesn't make things clearer. Going back to defining things relative to the CG makes no sense, since the CG is a nice location to tweak without screwing everything else up.

You're just confused since you already know too much. ;)
 
Ok, you can all get the patched CG exe at http://www.racer.nl/download/racer0826b.zip
It's around 1,5Mb (only the exe).

The fix changelist:

- move_cg=1 didn't offset correctly: cameras, wipers, generic models, brake calipers, exhausts, dials, helmet, carlights Z/far.

Note that I had trouble with generic models; the F458 uses them to add a cockpit model, which has to move internally to match the CG offset. For the Baja however, all the springs/dampers must NOT move, since they're positioned between 2 points, so should stay at their modeled positions (just like wipers for example). I now detect the 'from' field in a generic model; if that exists, I assume your stuffing the model between 2 endpoints. If not (the F458's cockpit), I assume it's a pure additional model, and translate that as well (visually you don't see anything translated, that's the beauty; you'll see really NO difference compared to v0.8.25, but internally everything is translated around).

Another problem were the cameras which required more work to be translated correctly, without pitch/roll/yaw affecting things.
 
Ahhhhhh ok.

So define the full car relative to NP, then simply adjust the CG so it's in the right place, probably best done WYSIWYG via CTRL 9 readout for height and weight distribution.


I'll still build relative to CG=NP=0,0,0 as it makes sense to me. You have to pick an NP while authoring, so why not just pick something roughly near the CG :D


Yes, I think my existing knowledge/process is confusing me.

But as you say, build as if the NP is the centre of the universe, and then as a final tweak, independently of EVERYTHING else, move the CofG to the right position using the offset. Makes lots of sense now :D


Fingers crossed this will mean more reliable content (though mine always had flat susp.y offsets and np=cg anyway :D hehe)

Dave
 

Latest News

Online or Offline racing?

  • 100% online racing

    Votes: 105 7.8%
  • 75% online 25% offline

    Votes: 139 10.4%
  • 50% online 50% offline

    Votes: 195 14.5%
  • 25% online 75% offline

    Votes: 379 28.3%
  • 100% offline racing

    Votes: 518 38.6%
  • Something else, explain in comment

    Votes: 5 0.4%
Back
Top