Racer v0.8.25 released!

Ruud

RACER Developer
Another one, esp important with the tangents problems (white spots/dark triangles):

Get it at http://www.racer.nl/download/racer0.8.25.zip

Changes:
- Setting racer.ini's textures.compression to 0 had an effect on visuals (no SRGB).
- Ctrl-1 now shows when the force feedback is saturating the wheel (>20 Nm).
- Controller setup screen now removed POV and added horn and wiper controls.
- 'sunny' default was 0, should have been 1.
- standard_bump_f.cg now takes specularity from the normalmap's alpha channel (2nd layer)
- Only 3/4 of the tangents was passed for each objects. White spots and black triangles.
- Baja shader bug fixed (dyn_standard_bump_speca.cg was used)
- ff_damping (in car.ini) was applied to the wrong FF setting (friction instead of damping)
- Small change in spline triangle checking for road surfaces; in Carlswood doing Shift-F
4 times failed to recognize the underlying spline triangle.
- Y offset in viewelt_f.cg removed; dials were slightly moved up a centimeter.
- Using Cg 3.0 toolkit (was 2.2) from July 2010.
- smCor for the 3rd shadow split slightly increased
- Only angular 3D view elements (dials) were painted correctly. Other texts could appear rotated.
- 'show splines' and all debug lines & points were rendered in HDR mode thus dark. Now drawn in LDR
after postprocessing to remain visible at all times.
- Live track envmapping anti-aliased the whole main FBO on each side update (ouch). Faster now
when setting render_once to 0.
- Mirror was anti-aliased twice. Slightly faster now.
- Exposure gradient changed from 0.5 to 0.35 (darker exposures)
- Music & background image handling in all setup screens now supported.
- More live track options in the graphics setup screen.
- Added bestline_v/f.cg for visible rendering of the 'best line' (F3 to toggle bestline)
- Added bestline.tga in data/images as an overlay image (uses alpha channel).
- 'sunny' included in sky shaders (GetSkyColorAtm) for the sun disc
- Undetected controllers would crash the controller setup screen in a few places.
- The lobby was painted incorrectly when using 3 monitors.
- Fixed stack underflow in car selection screen.
 
How to make wipers.

Make the wiper dof's, one for each wiper, pivot point located at 0,0,0 and then locate on car in car.ini file.

Put _wipers.7z code in body section of car.ini.

I like my controls.default.ini (_default.7z) file better than Ruud's, no double keys.

Was just thinking, is there any inter-penetration of DOF's ? You know, the windshield has a particular curvature & wipers (in real life) tends to deform slightly when moving...
Thx boomer !

Hm, that looks very much like they're using a couple of images (8?) and interpolate between those based on time. You see repeating effects. So you'd get 8 'normal' images (which deform the FBO in postprocessing) which are tweened as time goes bye. Nice but hope they've made it better by now.

LoL, I hope too...F1 2010 ones are looking better imo.
The interpolation stuff with 8 or more images in 1 dds/tga should be done for smoke as well as I've posted some time ago like NFS Shift does, hope to see a more real & random smoke soon...
 
QuadCoreMax,
Making the wiper dof's is tricky with none flat windshields, you just have to do the best you can.

Locating the wipers in Blender is really simple, just put the cursor on the car body pivot point press n-key snd read the x,y,z locations displaced from the body 0,0,0 point. Other 3D graphics programs may be able to do the same.
 
I just found something rather perplexing. I noticed that in 0825 my wip Mugello's barriers had stopped being collision objects, regardless of whether flags=2 (or 6). Carlswood was fine, just Mugello. Tried a few things, finally loading the barrier dof into modeler, generating tangents & exporting it again restored the barrier & other dofs to having collisions again. Just importing/exporting didn't fix them, nor did optimising dofs. Any ideas why Ruud?

& if this is the norm, can we have the optimise_dof funtions automatically generate tangents for dofs as well?

[edit]
after a bit of experimenting, it seems that modeler DOESN'T fix it.

If flags=2, collisions don't work.
If flags=6, collisions with object is fine.
I deleted cache folder in between every test

Any ideas why?

[/edit]
 
Hmmm that is weird.

I've had weird problems in the past with flags on the sky dome, and making it so certain cars didn't settle on their suspension.

Bizzare.

Have the flags changed at all? Does trackEd set a different number for a colission object now? Hmmmmm

Dave
 
I tried changing flags with tracked, it set flags=2, or flags=6. Neither tracked nor text editor made any difference, only flags=6 seems to work. One of the dof's is the 2nd entry in geometry.ini.
When I renamed the cache folder for carlswood, Racer recreated it, but flags=2 objects don't work as collide objects.

Further investigation, the racer zip contains a trackcollison.bin file for Carlswood, so it's possible it was generated in an earlier version, 0825's got a flags2 bug.

Can anyone replicate this? rename their carlswood cache dir, let Racer regenerate it, and see if collide objects then don't?
 
How to make wipers.

Make the wiper dof's, one for each wiper, pivot point located at 0,0,0 and then locate on car in car.ini file.

Put _wipers.7z code in body section of car.ini.

I like my controls.default.ini (_default.7z) file better than Ruud's, no double keys.

THX Bob, got the wipers working!

screenshot017.jpg

...yep atm are the static ons here too....
 
QuadCoreMax,
Making the wiper dof's is tricky with none flat windshields, you just have to do the best you can.

Locating the wipers in Blender is really simple, just put the cursor on the car body pivot point press n-key snd read the x,y,z locations displaced from the body 0,0,0 point. Other 3D graphics programs may be able to do the same.

I've made a very small tutorial on wipers at http://racer.nl/tutorial/wipers.htm
 
I've made a very small tutorial on wipers at http://racer.nl/tutorial/wipers.htm

Just as an observation.

I guess when outside the car, as long as they don't intersect you are fine, and obviously they shouldn't be too far from the screen. But in most cases you won't be close enough to tell.
When inside the car then you won't really be able to tell how far off the screen they are either, within reason.

I don't think the accuracy is too important here. Worst case could you even have an entry in the shader for these objects setting their sort_offset so they appear at the right side of the glass from either side... then some intersection would be ok without visual issues.


Hmmm

Dave
 
I just found something rather perplexing. I noticed that in 0825 my wip Mugello's barriers had stopped being collision objects, regardless of whether flags=2 (or 6). Carlswood was fine, just Mugello. Tried a few things, finally loading the barrier dof into modeler, generating tangents & exporting it again restored the barrier & other dofs to having collisions again. Just importing/exporting didn't fix them, nor did optimising dofs. Any ideas why Ruud?

& if this is the norm, can we have the optimise_dof funtions automatically generate tangents for dofs as well?

[edit]
after a bit of experimenting, it seems that modeler DOESN'T fix it.

If flags=2, collisions don't work.
If flags=6, collisions with object is fine.
I deleted cache folder in between every test

Any ideas why?

[/edit]

I have an idea yes. I skipped adding of collide polygons to the AABB tree, which is used for wheel-surface intersections. But the same procedure also builds Newton's collision tree! Fixed in v0.8.26. So in v0825 the pure collide polygons would not get inserted into the Newton collision tree.
In v0.8.26, I've modified it so Collide or Surface polygons are all processed. All surface or collide polygons are inserted in the Newton collision tree, but only the surface polygons are inserted into the AABB tree for Racer, so it's still a bit faster for wheel-surface tests. Requires you to delete the trackcollision.bin file when you get v0.8.26.
Sorry about that. I added some extra searching in v0.8.25 for the wheel-spline detection, since the spline triangle was not always detected (giving problems with Shift-F, Ctrl-Shift-F and also auto-reset). It became a bit slower, so I tried to optimize it a wee bit.

Temporary workaround: use flags=6 instead of just flags=2, or wait for v0.8.26 (since you want to get back flags=2 which is faster since it doesn't use those polygons for surface detection).

On v0826, that also adds a 'garage1' track, which is loaded as the background scene for the car selection screen. Terry here will make an initial garage, but it then is possible to make your own garage. The first pit position is used for the car position; the camera twirls around it a bit (need to make that a bit better yet). That fixes the white-car syndrome.

BTW All models get tangents upon load time, and 'Generate Tangents' does nothing effectively. Also, tangents are not saved (perhaps later when I have faith in the tangent creation functions, and I'll modify the DOF format a bit, after all those years). The button in Modeler is now 'Create template shader' which creates a shader file for all materials in the DOF. I used that to patch the Fer312 up for 0826 (not for real use but it loads so fast).
 
I don't think the accuracy is too important here. Worst case could you even have an entry in the shader for these objects setting their sort_offset so they appear at the right side of the glass from either side... then some intersection would be ok without visual issues.

As all opaque shaders are drawn first, then transparent ones, it might be indeed; perhaps some depthfunc=always helps when inside the car - even if the wipers are grossly intersecting the window, it would still *look* fine.
 

Indeed that is cool :D

The possibilities here are quite cool...

Just as long as the cars don't float around as they do in sim when they spawn at a location (very slowly of course... maybe need to force it to stay in one place if not already?!)

Will also be nice to add some extra details in as one car in a small room will allow for some really nice details/textures etc :D

Dave
 
As others have said before, I think this version is a good basis for a final candidate.

One major bug that would probably need dealing with though is the CoG offset issue, as it affects the vast majority of vehicles (only very few have their body mesh centered around the CoG, for zero offset in car.ini). Best would be to get to the root of the problem and remove it of course, but at least either disable the offset and/or make users aware of it's ill-doing in the documentation etc, I'd say?
 
As others have said before, I think this version is a good basis for a final candidate.

One major bug that would probably need dealing with though is the CoG offset issue, as it affects the vast majority of vehicles (only very few have their body mesh centered around the CoG, for zero offset in car.ini). Best would be to get to the root of the problem and remove it of course, but at least either disable the offset and/or make users aware of it's ill-doing in the documentation etc, I'd say?

Thats a good point.

The F458 that Cam is building was literally transformed in it's handling behaviour by putting the offsets to 0 and then moving the model appropriately to re-centre it.
Went from a finely balanced car to oversteering everywhere as if the CofG was on the back bumper, and spinning out in a line under even mild braking.

The impact of it is indeed very large and not ideal to have.

Ultimately, you are best off with CofG offset at 0 anyway, and then use the body model offset to get the position of it right. However, the issue with that is ALL the other models (like spoilers or additional ones) will need the offset too.


So yes, probably best to remove all offsets and make people get the null-point set properly... avoids all bugs/hassles then :D

Dave
 
Cool, was going to make a garage today actually.

Also, you/Mitch might want to have a look at this:
http://developer.download.nvidia.com/SDK/10.5/direct3d/Source/SoftParticles/doc/SoftParticles_hi.pdf

Since particles currently tend to intersect geometry atm.

I did a quick test; in our renderer we have a 'DEPTH_FIRST' switch which renders Z into a texture before rendering the rest. However, I got some Z issues. Probably nice after v0.9, instead of jeopardizing the engine again. Looks very nice though.
 
As others have said before, I think this version is a good basis for a final candidate.

One major bug that would probably need dealing with though is the CoG offset issue, as it affects the vast majority of vehicles (only very few have their body mesh centered around the CoG, for zero offset in car.ini). Best would be to get to the root of the problem and remove it of course, but at least either disable the offset and/or make users aware of it's ill-doing in the documentation etc, I'd say?

I re-tested and indeed, it is totally bogus. A Z offset of 1m does work statically when dropping the car, but it rotates around the nullpoint instead of the new CG. I've talked it over with a colleague and I'm reworking the CG to move all objects around. So that CG==NP and things like 3D models (pilot/helmet) en suspension/wings etc gets moved.
 

Latest News

How long have you been simracing

  • < 1 year

    Votes: 357 15.7%
  • < 2 years

    Votes: 251 11.0%
  • < 3 years

    Votes: 243 10.7%
  • < 4 years

    Votes: 179 7.9%
  • < 5 years

    Votes: 302 13.3%
  • < 10 years

    Votes: 260 11.4%
  • < 15 years

    Votes: 166 7.3%
  • < 20 years

    Votes: 128 5.6%
  • < 25 years

    Votes: 99 4.3%
  • Ok, I am a dinosaur

    Votes: 293 12.9%
Back
Top