Racer v0.9.0 RC4 released

[Ruud]

Another version... get it at http://www.mediafire.com/file/p79inu8n3mhani8/racer0.9.0_rc4.7z

The changes:
- Passing of scale and dt in motion blur done directly to motion_blur_f.cg
- 'graph delta ...' command did not seem to work. Fixed.
- 'show carpoints' now also paints the warp matrix (initial position/rotation)
- Task priority not set higher anymore; it can conflict with ethernet drivers apparently
- 'reset car' (or Shift-F/Shift-R) now also takes into account the initial roll angle (banking of the surface)
- lighting.cg could generate NaN when shininess was 0 (specular maps can do that)
- Onyx execution speedup by around 50% with function tables.
- Modeler now has a 'Unify materials' button to let the model use only the first material.
- Automatic transmission now accepts curves for better shifting; see http://www.racer.nl/index.php?jump=tutorial/gearbox.htm#automatic_transmission
- Onyx now supports equalities between ints (int i,j; if(i>j)...)

 

[Alexander Knoll]

Hi Ruud,
THX testing....

 

[Mr Whippy]

Ah automatic gearbox shift logic curves!

I think some people will be very happy with those

The authoring could be a bit more elegant though, would be cool if CurveEd could load up other curves purely displaying them as partially transparent as reference but not editable.


Looks like some other good changes too, but I've not really had a look at Onyx yet at all.

Will have a play later.

Thanks

Dave

 

[Ruud]

Ah automatic gearbox shift logic curves!

I think some people will be very happy with those

The authoring could be a bit more elegant though, would be cool if CurveEd could load up other curves purely displaying them as partially transparent as reference but not editable.

Looks like some other good changes too, but I've not really had a look at Onyx yet at all.

Those gearshift curves are indeed a useful feature; I created them to avoid tweaking a shift up/down rpm until a Formula-style car shifted correctly. Using the curves it's much more stable, although the velocity dependency is a bit weird at first sight (but that's how the people in the industry seem to do it). It also allows kickdown for example, which is nice.

And in fact, just for this, I forgot to note I see, I added 'Mirror Curves' to CurvEd, to be able to see the other curves. It's a bit crude; there's no legend to state which curve is which file, which I might need to add for clarity. But you *can* already now add a few (10) curves which are displayed behind the curve you're editing. Perhaps I should add a feature to mirror 'all the other opened curves', hm.

Onyx is something else; it's by large not complete yet, or at least, the interface functions aren't. I'm really building something on top of it, a much more data-driven engine in the end based on component/entity/systems (or attributes/behavior; it's actually called component/behavior currently). Very much in alpha stage though; hard to get your head round.

 

[Some1]

A bug! When live envmap is on, I get this nasty flickering of the particles in the env map. Also happened in RC3.

EDIT: Also, probably somehow related to my setup, but I get constant stuttering when using the auto_exposure (i'm running latest-ish NVIDIA drivers).

 

[Mr Whippy]

I created them to avoid tweaking a shift up/down rpm until a Formula-style car shifted correctly. Using the curves it's much more stable, although the velocity dependency is a bit weird at first sight (but that's how the people in the industry seem to do it).

They should be useful generally for any car, just a bit of a pain to set up at first but I guess there is some mathematically derivable 'default' you could generate from the max rpm and gear ratios to start you off with something that works ok. Just working it all out.

Yes it does seem to be industry standard, there are maps out there too so it could be as easy as copying real car curves to get the auto behaviour exactly as per the real model... a few DSG VAG ones are floating around.

I'm not sure how the data is stored on the actual ECU, but I assume it's probably a 3D map (these 2D maps stacked one after the other), probably in 16bit... I'll try get some binaries and find some real data it might be interesting

Dave

 

[SwiftPL]

Cool! Finally, I runned newest version Good FPS and graphics, thanks Ruud!

 

[Alex Forbin]

Nop

A bug! When live envmap is on, I get this nasty flickering of the particles in the env map. Also happened in RC3.

EDIT: Also, probably somehow related to my setup, but I get constant stuttering when using the auto_exposure (i'm running latest-ish NVIDIA drivers).

It's not your setup, this has been a problem for me for some time.
For what it's worth autoexposure is the first thing I disable, since it completely hoses the lighting.

Alex Forbin

 

[KS95]

I also get that, I blamed my crappy GPU though.

 

[Some1]

Nop


It's not your setup, this has been a problem for me for some time.
For what it's worth autoexposure is the first thing I disable, since it completely hoses the lighting.

Alex Forbin

I forgot to mention that auto exposure worked well (no stuttering) when I was running Win XP, now I'm running Win 7 (64bit)

 

[boomer541]

Thanks for the Update Ruud.
There were a lot of posts concerning sounds with spheres or something else but mostly gobbledygook in the last version thread, imho.
We have dust fir surfaces in the special.ini file and that is the ideal place for surface sounds as they are already available although they have to go to racer.ini to get them.
IMHO a suface should have assignable sounds with volume, reverb or whatever else the sound needs in the special.ini file where they belong! We could have glass breaking, potholes and a variety that has no end and be done with it.
Smple!

 

[luthobu]

Nop
It's not your setup, this has been a problem for me for some time.
For what it's worth autoexposure is the first thing I disable, since it completely hoses the lighting.
Alex Forbin

Hmm.. I thought that autoexposure was required for the shaders to look
right with bloom and all the other options (see previous post under RC3
thread). l'll have to look into this when I get home.

 

[Mr Whippy]

Auto-exposure just changes brightness automatically depending on the scene intensity, just like your iPhone video camera might do when you walk inside a house, it looks dark at first then it turns the exposure up so it looks light again.

The problem is sometimes it can be dodgy, but it's just bugs to be worked out. It works totally fine here from what I can tell...
...but if people are getting flickery particles then clearly something is wrong somewhere.


Turning it off is totally valid and ok to do, it just means that if you drive into the shade or a tunnel then it'll get really dark...

Auto-exposure is a good thing when it works right. I think whatever a DSLR does is probably a good way to work, since they usually meter scenes properly and they are fast!


As per the current auto-exposure, try turning the update from whatever it is to about 1500 or something. It'll react slower but it's still ultimately better than a static exposure but the cost on performance is much reduced!

Just like running live envmap at 1 side per frame is a lot less costly but gets you 90% of the benefits




Agree with Boomer on sounds, tracks/sounds should be definable per track just as we can for cars...

But imo the whole sound system is really limited and a big weak point for Racer right now.

Imo one of the biggest limitations of the current sound system is the dynamic range. It really is crazy to have HDR gfx but LDR audio.

HDR audio is probably the easiest thing to program in the world if you can make Racer haha, just add all your volumes up and then use an automatic gain system to get things sounding how you want them, with a user-controlled auto-gain amount so people could tweak to their preference!


It's nice to add new features for defining more sounds but if the sounds are still average even with more ability to customise then what is the point?

I'd rather have a few sounds per track but have the whole sensation being immersive, than have loads of cool interesting sounds played at wrong volumes and badly mixed with what is going on.

Ie, you won't even hear gravel noise or kerbs so much in an S-class Merc, but in a Caterham you'll hear them loads.
With some settings for say sound isolation on internal views (ie, subtract 15dB from external sounds if we are inside the car), then suddenly we get that feeling of being isolated in the car with a -15dB interior setting.

Otherwise we end up with people tuning their track sounds for their favourite car, then the next person comes along with their favourite car which sounds half as loud and the gravel sounds crazy and wrong haha...



Might sound overly complex but any decent content these days is hard to make and simply changing audio to a real unit value rather than an arbritary LDR one doesn't make an artists/authors job harder, if anything it makes it easier!

Dave

 

[camsinny]

Thanks Ruud!

Looks like I'll have to dust off the pedals and see if they work still.

I agree with Dave on the sounds - especially since I've become a bit of an audiophile lately and am pretty picky about sounds. It would also be a really nice way to differentiate between cars. A mazda might be X dB but then a lambo would be y dB and would completely drown out the sound of the mazda if they're both flooring it at the same point, however currently (assuming both cars have been setup with volume=1 for their samples) they'll be approximately the same volume.

I'll have a play with this new version and hopefully it'll get me back into developing some stuff.

 

[JustinMartin]

Found a bug with the automatic - the curves appear to use world velocity, not wheel velocity, so it doesn't upshift if you pass the shift point while spinning the wheels.

 

[boomer541]

Did Ruud mess with the cameras, Qlog error that was not in last version:
[racer] RCamera: camera1's offset and offset_to are too close - move them apart [rcamera.cpp:312 / RCamera::Load]
I have got to get more info and check this out a bit better. Anyone else having a simialr problem?

With special.ini sounds on surfaces one could make a pothole texture and sound and place them where one wanted and have them produce a bump for a car. Great for old bad roads.

I agree with Mr. Whippy about what he said above about sounds, good idea.

 

[Alex Forbin]

Did Ruud mess with the cameras, Qlog error that was not in last version:
[racer] RCamera: camera1's offset and offset_to are too close - move them apart [rcamera.cpp:312 / RCamera::Load]
I have got to get more info and check this out a bit better. Anyone else having a simialr problem?

With special.ini sounds on surfaces one could make a pothole texture and sound and place them where one wanted and have them produce a bump for a car. Great for old bad roads.

I agree with Mr. Whippy about what he said above about sounds, good idea.

Really you should switch to the new "head physics" style cameras, they work much better.

Alex Forbin

 

[boomer541]

Does that mean that every car made must use "head physics" cameras? The same car in ver 090_rc3 worked with out the error and not all cars have the problem and it's not with all cameras, just a few. Two cars with the problem are the Porsche 916 and the Simca Aronde. Try them and see if you have the problem also.

Besides, I don't like the "head physics" cameras as the fixed camera works very nicely for me! It's fine if you want to use them.

Another irritant is the new BLACK font, it's the same old font reversed. Can't Ruud leave things that work alone? The old font had white with black edging which worked unlike these that are INVISIBLE when the trees on carlswood are behind them!

 

[Cosmo°]

Agreed on the debug menu font colour - didn't we have this experiment before once already? It's a bad choice considering most of the time the background is dark grey/green.

There's a typo in the Ctrl+9 menu for "Theor. static weight% distributun (sprung mass)".

Shift curves are a convenient addition, makes it a quicker job to set up the behavior without trigonometric functions in scripts like I did so far. The fact that it uses world coordinate based velocity is actually positive, too, since from what I gather on a number of automatic transmission logics, in real life they do compare apparent vehicle speed (wheel rotational velocity) and engine rpm, engaging the shift only if the two parameters are reasonably well matching up.

It would be good to have more control in this area though - most importantly the ability to have a script logic call for a gear change that then looks up the corresponding curve file.

To expand on this a bit, for example I run a script on the Nissan GT-R that allows the user to choose between three transmission modes with their respective baseline parameters for shift duration as well as throttle and vehicle velocity dependent modifiers to arrive at the actual shift points for a given situation. On top of that there is restriction logic that prevents or delays shifts under certain circumstances, such as the TC being active for example. One particularly important aspect is the part that prevents upshifts into a braking zone, ie the driver lifts off the throttle paddle at high rpm and moves his foot over to the brake, during which time the simple automatic behavior in Racer has already shifted into a higher gear, which is obviously undesirable.

So for this I would want to be able to call out specific shift curves from within a script, so I can still impose rules on when and how a shift is meant to happen and under which conditions (shift duration, throttle blipping etc). That also means that a command is required that calls for a proper shift maneuver (including throttle and clutch modulation) instead of the crude, direct gear selection we're restricted to at the moment.



boomer: You don't have to use the head physics camera types. Since you're getting this error message about the offset and offset_to being too close to each other, I'm assuming you have them both set to the same value, which kind of defeats the point of using an SMD style camera at least partially. For fixed cameras, you're simply better off just using a fixed camera type, ie one that only uses angle, follow, offset - no offset_to, src, dst, and so on.

 

[JustinMartin]

The fact that it uses world coordinate based velocity is actually positive, too, since from what I gather on a number of automatic transmission logics, in real life they do compare apparent vehicle speed (wheel rotational velocity) and engine rpm, engaging the shift only if the two parameters are reasonably well matching up.

On modern electronic transmissions with wheel speed sensors on every wheel, that wouldn't surprise me. However, TH350's (very common GM 3spd automatic from the '60s-'80s) use output shaft speed to control full throttle upshifts. (and engine vacuum for part throttle upshifts) While I haven't experimentally verified this in real life, I can't think of any reason why a TH350 wouldn't upshift in a burnout. I suspect the same would be true for any non-electronically controlled automatic.

So we probably need an option to set which speed to use...