Racer v0.8.40 released

[Ruud]

A newer version. Get it at http://www.mediafire.com/?dm4nkc5bnn3j96n
The latest patch (textures in subfolders) can be found at
http://www.mediafire.com/file/g5i0mkhzbkcejmh/racer0_8_42exe.7z (exe/pdb only)

The changelist:

- User camera offset and angles now take an approach relative to the camera. It might take a while
to get used to it compared to the old method.
- User camera offset/angle works with fixed & free (SMD) car cameras.
- Selecting graphics options and then doing a race would not have any controllers loaded.
- Look left/right works again (although not set by default; go into Controls)
- Onyx classes now supports member functions (no constructors yet)
- Added Onyx mouse functions to get coordinates & buttons (see data/scripts/onyx/include/racer.oxs).
- Added timing.fixed_time_step for ultrasmooth graphics; set vsync=1 and fixed_time_step to 0.016666
for example for a 60Hz screen. May go wrong when Triple Buffering is turned on though.
- Shadowmap rendering pass will now invert culling (instead of turning culling off entirely).
- TrackEd's Split function would generate bad DOFs if more than 21,845 (or perhaps 65,536?) vertices were present
in a single cell. Now it will generate multiple DOFs, each containing at most 21,000 vertices.
- Replay exporting development using DirectShow (instead the ancient VideoForWindows) to get better
video files. May requires openglfilter.ax to be registered (run 'regsvr32 /s openglfilter.ax').
See http://www.racer.nl/index.php?jump=tutorial/replays.htm
- Replay export using DirectShow (replay.video.type=2) now requests a filename (intermediately generates replay_TEMP.avi/wav).
- Replay format changed; now stores the driver names as well and can display those in replays (if show_names=1 in racer.ini).
The format is incompatible with previous replay formats.
- Added replay.auto_save, replay.database.dir for more control on saving replays
- Added support for custom reflection maps in tracks, see http://www.racer.nl/index.php?jump=tutorial/reflection_map_creation.htm
- audio.frequency was unused for a long time. It became apparent when writing replays where timing was off due to 48kHz vs 44.1kHz
discrepancies.

For an interesting experiment, download http://www.mediafire.com/file/04t1dvj6tl2qyvb/WORLD.7z and put the files in data/tracks/carlswood_nt. Very alpha stuff.

 

[boomer541]

Thanks Ruud for the update, your work is very much appreciated! BUT...

I don't like the new camera being referenced to the camera position due to being cery eamiliar with using the keypad to rotate round a car or adjust a view is damn near impossible now. Version 0.0839 was almost perfect, but it refernced the camera location to the cog and the car camera s/b referenced to the car nullpoint as it makes determining angles ,etc. soooo much easier and simpler, kis Ruud.

Now to find some of the problems with this version... Qlog has too much stuff in it now, for one.

 

[DavidI]

I agree with Boomer on the cameras, it's just not intuitive as it is.

 

[QuadCoreMax]

• I've just noticied two bugs, first, when i do a lap, then i've the ghost car, and when i turn on the lights of my car, it's done to the ghost car and not mine

Since you talking about, try to fix the same when AI racing & controlling AI lights properly, that means per car...or give us another console variable to manage them. (ai lights on/off or 0/1)

=============================================
Racer-Max Portal (New) - Free Tracks, Cars & Tools for Racer

 

[Alex Forbin]

I tried your 2 scripts (paint/physics); named them both genmodels.rsx, and it worked in one go. Can you provide me with an entire car that doesn't work at once in v0.8.40?

Sorry for the late reply I've been out of town.
Sure. How can I get the model to you?

Alex Forbin

 

[boomer541]

What do you know, there are a few bugs in ver 0.0840-0.0841. The image numbers and a description of some of the problems.
1. Ver 0.0839 has good shadows in my Surfaces and Sounds track compared to...
2. Ver 0.0841 where the shadow is OFFSET for what ever reason.
3. Ver 0.0839 has a shadow cast by the vertical sign compared to...
4. Ver 0.0841 where did the shadow go for the vertical sign. Shadow heaven perhaps, only Ruud knows.
5. Ver 0.0839 shows good car shadow with cast_shadow=1 on most all car shaders compared to...
6. Ver 0.0841 which is the Default Lambo which doesn't have cast_shadows on the proper shaders. And shadow is offset. Should have all shadows and let car/track creators set cast_shadow=0 as needed.

A track/car without good shadows is a bit unrealistic, IMHO

I also get a 60 fps drop compared to ver 0.0839. 332 on 0839 vs 279 on 0841 using the same car/track and car location point. It vsync is 1 - 279 fps or 0 - 263 fps on ver 0.0841. It doen't change the fps if audio freq is 44100 or 48000. Got it working by setting nVidia card to use racer vsync. little bit tricky to set up.
With vsync=1, trip buffering and fixed_time_step=0.01666667, get nice solid 60 fps on carlswood WOW! Other tracks don't work correctly, they slow to a crawl in places.

Do we use 44100 or 48000 for the audio setting? 48000 sounds better imho.

Cameras are another irritant. They were working quite nicely in Ver 0.0839 even though they were refernced to the COG. Change the COG and the camera moved. With ver 0.0841 car.ini cameran.offset x,y,z all = 0.0 the camera is at the car nullpoint and I get a Qlog error the offset and offset_to are to close Adding the cameran.offset_to with x,y,z some value I expected the cameraa to move to the offset_to point and then with the keypad numbers have the camera rotate round tthe car nullpoint. BUT NOoooooo. it rotates round the offset point(nullpoint). reversing the values and the camera moves to the new offset point and rotates round that point. Bummer the keypad numbers just don't work righ anymore they are useless!!!!!!
Ruud Please go back to the ver 0.0839 cameras, Please!! Does anyone like the new cameras?

Recording a video don't work, tried both type 1 and type 2. type 1 crashes and type two doesn't play the audio when playing recorded video. Also no dust in grass.

Menu text barely readable s/b all black lettering

No track, helo or director cameras if car not on track. Camera switches to car if it goes off track on carlswood only, I can't remember where this track setting is setup.

Ghost car - See #5 below.

Don't you just love the "improvements"?

Reported Ver 0.0839 bugs that were evidently forgotten about - - -
1. moveables down when running watkins track was ok in ver 0.0837
2. no sparks when rubbing guardrail, etc.
3. look left, right, up, down not working. -- -- Fixed Thanks Ruud
4. car bounces back when doing a skid sideways stop -- -- Fixed Thanks Ruud
5. car lights on with ghost car - only ghost car lights come on and wheels don't turn
no car or ghost lifhts and can't see the ghost car.
6. backfire not correct, remains pointed in one direction
6. FF problem when reload_car command in console
7. glass in tracks have reflections not good with live envmapping on LE eats about 75 fps. same for cars
8. Max_alpha in particle.ini no longer works.
9. Camsinny colorgrading problem.
10. Damage image s/b able to move to a different position in data/gui/globalvies.ini

 

[Mr Whippy]

The camera system makes sense now.

The old behaviour of everything moving about the car null point didn't make sense as it limited our camera techniques.

All we need to do if we want a camera we can tweak with while playing Racer is to set up a camera that has the offset_to at the car null point. Say put that camera on number 5?



For me personally when I load up a track with Cosmo and go for a drive, I NEVER touch any view except bonnet or interior view. While in interior view I constantly struggle with the realism of the motion. I can't tell how hard I'm steering, braking or anything because of the 1 DOF offset of the camera.
Now we can have a really nice 2 DOF movement because the camera can move relative to an offset point under SMD (because of the angle being offset to the direction of movement if we want)
That gives us some really nice power.


So some loss in development flexibility, but as said, surely we can just have offset_to on the car null point for a few cameras during dev, and they work just as before?


I'm generally positive on this change, and am happy to give it a try

Perhaps coding in the above effects via Onyx may have done the trick instead, I'm not sure...



I've not managed to have a go yet, Mediafire isn't being nice to me


Cheers

Dave

 

[Stereo]

All we need to do if we want a camera we can tweak with while playing Racer is to set up a camera that has the offset_to at the car null point. Say put that camera on number 5?

I think something like this would make sense, an optional fixed origin. I don't know if such a thing can be configured right now though, it seems like the camera controls always rotate around the current location of the camera.

 

[boomer541]

Mr Whippy,
I tried what you said and did a bit more as follows:
With ver 0.0841 car.ini camera5.offset x,y,z all = 0.0 the camera is at the car nullpoint and I get a Qlog error the offset and offset_to are to close. Moving the camera with the keypad and the camera rotates round the moved to point.
Adding a camera5.offset_to with x,y,z some value I expected the cameraa to move to the offset_to point and then with the keypad numbers have the camera rotate round tthe car nullpoint. BUT NOoooooo.
It stays at the offset point(nullpoint). Moving the camera with the keypad some distance, the camera rotates round the moved point.
Reversing the values and the camera moves to the new offset point and rotates round that point. Bummer the keypad numbers just don't work the way they did in ver 0.0839!

You evidently haven't tried it, Please do so and then tell me the cameras work "just as before".

 

[Mr Whippy]

I don't believe they work just as before, but I can't check yet. Mediafire is still giving me grief with the download (has the download limit been reached or something?)

I've tried a few browsers and two machines and both of them are just sending me in circles with failed download, try again, catchpa stuff...


But any way, what about using the ctrl num-keypad, do they still move the camera origin in xyz? So can you move around a car still, but it's more clunky to do so and not very elegant?

I think there will be an obvious fix for this which simply makes the camera move keys do the appropriate transforms to make the camera move around like it did before, even though the actual coords and stuff are using the new more 'complete' system!?


Is anyone kind enough to share an independent link to the download? The Mediafire hosting seems a bit hit and miss. We really should go for a torrent system imo since I generally leave my torrent program open most of the time (full up with Falcon BMS stuff right now hehe)

Cheers

Dave

 

[Stereo]

I don't know that this will work or not, but it's worth a try...
magnet:?xt=urn:btih:IHRDWXKRMNRELDED6YWN3WHE5PH77JWI
It's racer0.8.40.7z & racer0_8_41exe.7z, in a torrent. Might take a while since I'm the only seeder.

 

[Mr Whippy]

Yay, thanks for sending me it Cosmo!

Yeah Boomer, it isn't so elegant to pan around a car any more... hehe... not a huge issue *IF* we have something simple like shift + numpad to make the movement lock to the car rather than the camera for transforms... probably a relatively easy tweak to make considering the libraries Ruud will have for such things these days!


I'm a bit disappointed to see that angle is still not used with SMD though. From what Ruud wrote in the release post we could set angle variables so for example we could have an SMD camera but on it's side rather than 'flat' to the world. Or at 45deg, or other artistic implements like that.

Unless angle is implemented but the car.ini syntax has changed? It used to be angle{} but might now be something different *IF* angle offsets really have been implemented for SMD?!


Hmmmm

Dave

 

[Mr Whippy]

Thanks Stereo, but already have it off Cosmo

Just had a look, Ruud does specifically say angle/offset now work with both static and smd cameras... but unless the syntax has changed it's not working here


Ruud, have you managed to rotate an SMD camera so it's looking up, despite the offset/offset_to locations defining a path looking forward for example?

The Racer.nl page here:
http://www.racer.nl/tutorial/car_cameras.htm

Doesn't show the angle variable for 'free' smd cameras... is there a new syntax for adding angle variables for the smd types? Ie, offset_angle or something (I'm trying random values but don't want to waste my day looking for something that might not exist )

Thanks

Dave

 

[Mr Whippy]

Well, you can fudge the effect I'm after.

Set any interior car camera so offset_to is the same as offset.

Adjust the y coord so it's about 50cm lower.


Load up Racer, and now use the numpad2 key to angle the camera up and looking forward again.

Now when you accelerate the camera tips back, and brake you get tipped forward. Steering gives you a rocking side to side motion.

It may not be ultra realistic, but it's a great deal more useful as visual information since the offset in angle is more memorable with regards to the g-force acting on the SMD, than pure linear offset in position.
Ie, 5deg vs 10deg lean in a bend is easier to articulate to a doubling of the lateral g forces vs 5cm vs 10cm offset laterally for instance.

You essentially get something similar to Tor Arne's key-ring g-meter from his MR2 back in the day. You can 'see' the g forces a great deal more when something changes it's angle than when it is merely offset in the same plane you are in.


Any way, that is nice. Now all we need is to be able to set the angle in the car.ini hehe...


Already makes driving much easier. With good tyre noises I can now really get a feeling for how many g's I'm cornering at without looking at a g-meter... on the road IRL when I corner at 1g (eek) it's very dramatic, and the same with braking... so now I can articulate that with quite large angles that make things more dramatic, without having an SMD camera moving linearly like before which just felt silly if it moved much more than 5cm!


Cheers

Dave

 

[Alexander Knoll]

...hmm..Dave it sounds as you are the only one who like the "new" cameras...

 

[Mr Whippy]

The only thing wrong with them is the focus point for rotation. If Ruud can just make it so when you press say 'shift' that the numeric keypad rotates/moves the camera about the car null point, then it's fine again.

But in actual practice these new cameras give us lots more flexibility. Ie, walking around the car in a 'virtual garage' type environment. Perhaps improves the possibility to add head tracking more easily as it's local to the camera?!

Loads of reasons to be positive, despite the initial issues with it from a user interface/development point of view...


Cheers

Dave

 

[Ruud]

What do you know, there are a few bugs in ver 0.0840-0.0841. The image numbers and a description of some of the problems.
1. Ver 0.0839 has good shadows in my Surfaces and Sounds track compared to...
2. Ver 0.0841 where the shadow is OFFSET for what ever reason.
3. Ver 0.0839 has a shadow cast by the vertical sign compared to...
4. Ver 0.0841 where did the shadow go for the vertical sign. Shadow heaven perhaps, only Ruud knows.
5. Ver 0.0839 shows good car shadow with cast_shadow=1 on most all car shaders compared to...
6. Ver 0.0841 which is the Default Lambo which doesn't have cast_shadows on the proper shaders. And shadow is offset. Should have all shadows and let car/track creators set cast_shadow=0 as needed.

A track/car without good shadows is a bit unrealistic, IMHO

I also get a 60 fps drop compared to ver 0.0839. 332 on 0839 vs 279 on 0841 using the same car/track and car location point. It vsync is 1 - 279 fps or 0 - 263 fps on ver 0.0841.

Can you send me that track with the shadow issues? (or do you have a link?)

With vsync=1 btw, you get >60fps? If your driver is set to leave vsync up to the application, it should stick to 60, perhaps if triple buffering is on it might go higher...

 

[Alexander Knoll]

Can you send me that track with the shadow issues? (or do you have a link?)

With vsync=1 btw, you get >60fps? If your driver is set to leave vsync up to the application, it should stick to 60, perhaps if triple buffering is on it might go higher...

öhm...

http://www.racedepartment.com/forum/threads/track-list-0-90-ready.51120/#post-1157077

°|°

 

[boomer541]

Ruud,
Alex beat me to it, the track link is post #7 to alex's link. I have a nice waterfall on it and look at the tunnelobject and car shadow offsets while working on the shadow problem.

I did get the vsync worked ot so that I get a steady 52 to 60 fps on carlswood. I did note that ver 0841 eats about 60 fps. I do have triple buffering on all the time. Just wonder where the fps went, 332 down to 279 is a big drop.

I gues that Mr. Whippy agrees with me about the car cameras.

Don't forget about the problems left over from 0839 that I mentioned, please. Exception, backfire: works fine on lambo but not real good on a few other cars, don't know why yet as Im still working on that one myself.

Lots of problems need fixing as we move towards a stable v. 0.90 and I really appreciate all your hard work, sometimes wish I could learn programming.

Enought o keep you busy for awhile.

 

[Ruud]

The only thing wrong with them is the focus point for rotation

The camera handling was changed due to a project with headtracking (not with HUDs but a bigger movement requiring predictive headtracking). Since the keypad keys worked differently for SMD and fixed cameras (and really also quite different in their implementation; the position in the transformations where the user angle/offset was added) I decided to rework the code so that you had a post-transformation matrix which was the same for both types of cameras. I also actually added a headtracking matrix (a 2nd post-transform matrix) which deals exclusively with headtracking itself. This because headtracking and user movements are 2 different things and needed to be handled independently.

The new method is based on seeing movements relative to the camera's current position, as if you were the cameraman. I agree that it is hard now to rotate around a car (or focus point). It is technically better (i.e. I won't go back) since it handles user and headtracking transforms much cleaner, so I'll try and add a focus point rotation point instead. For example using the Alt or Ctrl key, a bit like what you can do in Max/Unity.

@Boomer: the shadows I discovered were an effect of using inverted culling while rendering the shadowmap. It seems it doesn't work in all situations, so I've put it back to cull=none for all materials for the next version.

 

[DavidI]

...so I'll try and add a focus point rotation point instead. For example using the Alt or Ctrl key, a bit like what you can do in Max/Unity...

Why not add a racer.ini flag to change the operation of the keys, and set the flag by default to make the keys move the view around the focus point similar to before? I assume you suggested a modifier key as you need the headtracking software to 'press' the keys, but the majority of users aren't going to be using headtracking, just expecting the keys to move the view as previously. The headtrackers could then just change the racer.ini flag to modify the keys to suit themselves, leaving the default operation as the majority prefer & expect?