Racer v0.8.37 released

Ruud

RACER Developer
Just in time for X-mas. ;)

Get the new version at http://www.mediafire.com/?hc44aiq5izp4iqi
Then get the racer.exe/pdb which fixes reflections at www.racer.nl/temp/racer0838_alpha.7z

At some point we're going to have to call it v0.9rc1, since this one does a little tweaking to the graphics intensities (energy conserving) and sets cast_shadow to 0 by default. Most shadows will disappear; a huge fps boost until you put shadows back in shader files (.shd).

Merry Christmas!
Ruud

The changelist for v0.8.37:
- Added views.ini keep_aspect property to maintain aspect ratio for static images. See http://www.racer.nl/tutorial/dials.htm
- dyn_standard_reflect_window_f.cg now uses alpha as reflectiveness as well; opaque parts get less reflection
- TrackEd's AutoAseToDof has improved error messages on bad submaterial usage.
- TrackEd: some (progress) dialogs never appeared. Copy flags to group didn't work.
- TrackEd now colorizes the Collide and Surface flags in Props mode (F4) for easy tweaking of flags.
- standard_bump_detail_f.cg had a hardcoded 12x scale; now it uses the scale defined in the .shd file
- The garage track is not shown in the 'Select Track' screen anymore.
- Added log.events.host/port settings for remote racer tracking (niche usage).
- Lidar data (track.rld files) can now be sorted and driven on. Pro use only.
- Added car pitch/roll in body AND world coordinates in the Ctrl-9 debug screen.
- Added 'analyse shaders' command to check all shaders (track.shd/car.shd).
- The shaders default 'reflect' value for each layer is now 0 (was 1).
- Final tweaks in the shading system; energy conservation for diffuse and specular. For diffuse colors, this
means diffuse colors are divided by PI (assuming diffuse colors are kept between 0 and 1), and specular
colors are being corrected with (n+6)/8*PI.
See also http://www.rorydriscoll.com/2009/01/25/energy-conservation-in-games/
- Timers are now in microsecond accuracy using QueryPerformanceTimer(). Multicore machine issues?
- Profiling is more accurate due to the better timer accuracy. More graphics divisions added.
- Shader cast_shadow property by default is now 0; it's better to explicitly define shadow-casting materials
since you don't need a lot of shaders to cast shadows to still get a good image.
You *will* need to add cast_shadow=1 lines for shaders that you want to cast shadows.
- Depth texture setup optimized for shadowmapping; quite a big fps increase.
- Added look/left right controls (look_left, look_right) to dynamically look left or right (Q/W by default)
- In your controller file you can add global.left_right_look_velocity to set left/right look velocity (default=250)
- In your controller file you can add global.left_right_look_max to set the max left/right look angle (default=45)
 
@Dave

Right I see, it's not that I haven't used the 'reload shaders' command, it's just it's really buggy, it's like the wireframe command which indeed is scaring....thinking of Camsinny here, rofl !

If that issue is fixed, I suppose we can then create a simple garage in town, where with some pictures (descriptions of commands/function triggered in script) & keyboard press (buttons to actually execute wanted functions), you change the car color dynamically via scripts something like firing the reload shader command at certain intervals in the script...& above all, continue to drive without having any frustum bug.

Or am I completely wrong, please correct me if you know better or have better ideas ?

@Ruud

Ah, talking about buttons & mappings, can you give us the ability to assign certain functions/commands to our G25/G27 buttons ? Would be great ! For example, the little up/down/left/right joystick could be mapped to the camera, & others to scripts/commands etc...;)
 
:) It's already there !



:D using now the new scripting framework & you should be able to do a lot of things with some imagination !
For example, instead of using the TOD via its curve file, you could re-create it in an ini file with all the custom variables + with snow/rain/etc..& use it in your scripts.

Another cool example would be to try out real snow with movables & joints/skeletons, you remember my tree example ? the same idea but for snow, that means creating a snow flake (real thin closed rectangular shape like mesh) + with the most littlest sphere collision mesh assigned to it (via Tracked) to finally use it ingame & distribute them via scripting.

Those little spheres would then interact 'naturally' with car tyres,

Don't forget performance; there's a reason why you don't add millions of collision spheres and do snow that way...
On Flash, I'm not sure how that would be integrated into Racer; interfacing with external API's is always kind of a nasty path.

The internal script engine is probably capable of some things like active suspension with the system set/get commands now. It's compiled to bytecode so not too slow, and runnable at 1000Hz.

I wrote an external shell for Doom once, see http://jwkorver.home.xs4all.nl/ , which did all the option stuff, and then ran Doom with all the options specified. In the end that should all be just in Racer, as Mr Whippy says.
 
A note on the cameras; a change at some point was to modify offset_to to be closer to the car, to get shadowmapping to focus on a point close to the car, rather than far away. I noticed that the Lambo in camera4 though uses a from point that's 6 meters away from the car, and the 'to' point is also far away! That means that neither the camera from or to point is useful as a focus point for the shadows.
I've modified that to use an explicit focus point, namely the center of the car (perhaps it should be somewhat in front, since you normally look there).

That also means I reverted the normalizing of the 'offset_to' point, which should make the trailing cameras work again (since effectively the camera target point was moved to be 1 meter away from offset_from).

On all the garage/color changing things: I get that scripting should play a bigger part. Scripting might be the future of the gaming experience even, hm, to be able to do more fun stuff that nobody though of yet.

On 'reload shaders'; I use that a lot; when is it buggy? Wireframe is already fixed in the later exes I posted here, and it's a debug feature anyway, so doesn't really need to be 100% fullproof.
 
Don't forget performance; there's a reason why you don't add millions of collision spheres and do snow that way...

Was joking :)

1 way is to set according grip amount via script relatively to the snow amount when 'fast_time xxx' with a nice animated snow terrain texture (almost like damage shader with the time variable) & finally interpolate some TOD values via commands sent from scripts with clouds/sunny/etc. Eventually, a listening to the actual surface material to set different grip amounts (get (rcar) wheel (int) surfacetype)..etc.

All good stuff !!
Ah, since you talking binary, what should I know if I want to build a similar Maya Racer plugin as recently done with 3DS Max ?
& what about some of the car.ini values directly set from Max/Maya/Blender & exported via the plugin ?

With your ini exe program plugged together, the backfires, the camera, the wheels/steeringwheel & suspension positions, etc..could be set/written directly to the chosen car.ini....to be thought !
 
On 'reload shaders'; I use that a lot; when is it buggy? Wireframe is already fixed in the later exes I posted here, and it's a debug feature anyway, so doesn't really need to be 100% fullproof.

Oups, still on 0.8.36 & waiting patiently, but I still have issues, when reloading shader, even doing a reset of the track doesn't fix the fact that I have to exit & reload track to actually be able to drive my changed colored car again, i.e.

Or am I just doing something wrong ?

reloadshaders.jpg


==================================
Bug ?

Playing with multiple ai cars (racer.ini tweak), I get no AI car reflection on my AI cars bodies....Strange from memory, the animatables were correctly projecting reflections when in motion...
 
I've uploaded a test version with fmod 4.30 (the old one) at http://racer.nl/temp/racer_0838audio_bug.7z
Download that, put the files in Racer's directory and rename fmodex430.dll to fmodex.dll (FMOD won't complain if the DLL is NEWER, so check the filesizes). FModex.dll v4.30 is 385Kb big, v4.36 is 780Kb.
See if that resolves the audio issue and let me know.

EDIT: please redownload the above .7z! (5:56pm here in Holland). It was really mostly a v4.36 load still, now it is the real FMod4.30; it should not work with the newer fmodex.dll, only with the 4.30 fmodex.dll


You're the man. :) It works! The initial sound levels are correct, tried reset and reload car, it all works great.
Thanks.

Alex Forbin
 
I wrote an external shell for Doom once, see http://jwkorver.home.xs4all.nl/ , which did all the option stuff, and then ran Doom with all the options specified. In the end that should all be just in Racer, as Mr Whippy says.

+ 1 Ruud, what a coincidence, Heretic was my favorite game back in the days !
I just tested it for fun, there seems to be a duplication of screen display occurring in Doomsheel, hmm maybe you could ask or check Kegetys, he knows how to handle multiple screens correctly.

With Racer, in fullscreen, my Racer displays from the middle screen into the right monitor only, the left monitor not been used. I think for surroundings configs, we need a racer.ini dispaly order option. I have 3 1 2 config....which could work if Racer is smart enough to listen to the display adapters & set automatically Racer window.
 
Don't forget performance; there's a reason why you don't add millions of collision spheres and do snow that way...
It would still be nice to have some access to collision detection for certain particle applications, for example sparks would look better if some of them bounced on the ground, an engine could spew some "gibs" on the road indicating the demise of an engine and the impromptu piston exit from the side of the block. $$ A few "mist" particles that ran down the face of a waterfall and flowed across the pond a little ways would add some realism.
Granted it would kill the framerate to go crazy, but like spice I think a little could go a long way.
???

Alex Forbin
 
It would still be nice to have some access to collision detection for certain particle applications, for example sparks would look better if some of them bounced on the ground, an engine could spew some "gibs" on the road indicating the demise of an engine and the impromptu piston exit from the side of the block. $$ A few "mist" particles that ran down the face of a waterfall and flowed across the pond a little ways would add some realism.
Granted it would kill the framerate to go crazy, but like spice I think a little could go a long way.
???

Alex Forbin

Hehe, well nice ideas but really... let's be realistic! It would be nice to get the simple collisions working correctly under all conditions. :)
 
In v0.8.38c, vehicles equipped with a non-type=3 (limited slip) differential throw a false qlog message, which didn't happen under v0.8.37 yet:

Code:
Mon Jan 09 20:26:29 (WARN): [racer/3724] power_ratio=0.00; diff ratios should never get below 1.0 - unrealistic (using 1.0)
Mon Jan 09 20:26:29 (WARN): [racer/3724] coast_ratio=0.00; diff ratios should never get below 1.0 - unrealistic (using 1.0)
 
It would still be nice to have some access to collision detection for certain particle applications, for example sparks would look better if some of them bounced on the ground, an engine could spew some "gibs" on the road indicating the demise of an engine and the impromptu piston exit from the side of the block. $$ A few "mist" particles that ran down the face of a waterfall and flowed across the pond a little ways would add some realism.
Granted it would kill the framerate to go crazy, but like spice I think a little could go a long way.
You don't need to run full physics for all the particles - just flag some as 'keys' and then other nearby particles act the same. So you block the key particles from moving through objects (or scatter them in new directions), then other ones around them tend to stop or bounce too.
 
You don't need to run full physics for all the particles - just flag some as 'keys' and then other nearby particles act the same. So you block the key particles from moving through objects (or scatter them in new directions), then other ones around them tend to stop or bounce too.

An interesting idea. It would be sort of like a flocking algorithm. But as Someone said it should be not problem to have basic physics that run properly, it would be up to the track/car authors to stay within reasonable bounds just as it currently is with polygon counts.

Alex Forbin
 
It would still be nice to have some access to collision detection for certain particle applications, for example sparks would look better if some of them bounced on the ground, ...
I agree, but first up, how about more realistic rain, that interacts with the ground & objects, instead of just disappearing thru the ground. It looks too Matrix-y as it is!
 
On 'reload shaders'; I use that a lot; when is it buggy? Wireframe is already fixed in the later exes I posted here, and it's a debug feature anyway, so doesn't really need to be 100% fullproof.

Same here. Wireframe is buggy but it didn't really worry me as it wasn't designed for outputting imagery from.

I use reload shaders lots too, and it works flawlessly. I had issues when it first was added, but in the last year it's been a bulletproof feature!


Cheers

Dave
 

Latest News

Are you buying car setups?

  • Yes

  • No


Results are only viewable after voting.
Back
Top