Racer v0.8.31 released!

Ruud

RACER Developer
Just before the weekend... v0.8.31

Get it at http://www.racer.nl/download/racer0.8.31.zip (75Mb)

Changes:
- Added racer.ini dev.note_ini_unused to check for unread car.ini parameters. See also http://www.racer.nl/tutorial/development.htm
- Color grade shader improved.
- The wind could get stuck in growing infinitely, making particles shoot away after a while
- Differential reworked, since it had a bug (it accepted ratios <1.0).
- Clutch wasn't restored after shifting when autoclutch was 0 in racer.ini and the car.
- Flare colors could dip below 0 (weird colors) when using non-klux flare color values
- Flare default color is now '40 40 40' (was '1 1 1'), see also http://www.racer.nl/tutorial/car_lights.htm
- TrackEd would save splines where lines.paint_end would always be the number of splines, even if you specified less
- TrackEd would overwrite the gfx.sky values in special.ini with generated values (when saving)
- TrackEd still used Newton 2.26, so loading any track would recreate trackcollision.bin. Upgraded to Newton 2.29.
- Flare billboarding now screen-aligned by default; see http://www.racer.nl/tutorial/car_lights.htm#flares
- A multiplayer client pressing Shift-R would get stuck waiting for a race start. Now modified to let Shift-R behave as Shift-F.
- Smoke/grass particles no longer spawn when a wheel is off the ground.
- Traction control gives a warning if a ratio is <=1.0 ; that gives serious jitters.
 
I don't recall how it was done...you mean extracting the avi/wav from the movie/rpl file ?



You could create your own clouds planes, typically that's how it's done. I originally had the idea to animate them with bones/skeletons around the scene & trigger them with triggerlines for example. That way, they would become dynamic & increase the realism of your scene/track map.



It's cool to virtualize noise which doesn't exist in your road model, but I think it needs more tweaking possibilities where we would get a better control on how those road noises get spread over it. Maybe some kind of a graphical debug ingame...

Still, I don't use enough the graph command, for now I have an error message :
Unknown graph var 'wheel0.road_noise'

====================
What about flags/geometry.ini file ?
It seems broken, even though I deleted the bin file for reset...

The noise feature is really handy indeed, especially for roads etc.

Maybe the syntax posted is wrong. Doh.

The noise could be more powerful, but apparently it's already fairly costly on CPU/physics time... I think if you are willing to tinker with values you can get worth while results from it. Most games don't even offer it from what I can see, so Racer should be applauded for having it at all imo :D
That said, having better meshes is a better idea too... plenty of data can go in fairly high density meshes these days, leaving noise just for the 'texture' of the surface more, perhaps... hmmm...

Dave
 
DERP.
Accidentally forgot to build my .ar and put it in the car's root. Nevermind.

Though it would be nice to have something a little more descriptive than:
Code:
Tue Jan 25 09:47:56 (FATAL): [racer/1700] Exception 0xC0000005, flags 0, Address 0x0041609D
(this dialog text is stored in QLOG.txt)

OS-Version: 6.1.7600 () 0x100-0x1

0x0041609D d:\source\trunk\dev\src\libs\d3\dgeode.cpp (line 239): DGeode::GetBoundingBox()
0x004E26B9 d:\source\trunk\dev_racer\src\ui_public\selcar.cpp (line 491): AutoScaleCar()
0x004E2AFE d:\source\trunk\dev_racer\src\ui_public\selcar.cpp (line 569): LoadCar()
0x004E2BC9 d:\source\trunk\dev_racer\src\ui_public\selcar.cpp (line 241): MoveCamera()
0x004E2FCE d:\source\trunk\dev_racer\src\ui_public\selcar.cpp (line 378): CarPaint()
0x004E32DF d:\source\trunk\dev_racer\src\ui_public\selcar.cpp (line 613): idlefunc()
0x004E3309 d:\source\trunk\dev_racer\src\ui_public\selcar.cpp (line 627): Do()
0x004E3793 d:\source\trunk\dev_racer\src\ui_public\selcar.cpp (line 768): rrSelectCar()
0x004DA90E d:\source\trunk\dev_racer\src\ui_public\menu.cpp (line 1741): Do()
0x004DAACB d:\source\trunk\dev_racer\src\ui_public\menu.cpp (line 1864): RMenuRun()
0x004034EA d:\source\trunk\dev_racer\src\mrun.cpp (line 1678): Setup()
0x0040383E d:\source\trunk\dev_racer\src\mrun.cpp (line 1937): Run()
0x00401504 d:\source\trunk\dev_racer\src\main.cpp (line 222): main()
0x00401573 d:\source\trunk\dev_racer\src\main.cpp (line 229): WinMain()
0x0055460B f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c (line 263): __tmainCRTStartup()
0x75FC3677 [kernel32]: (filename not available): BaseThreadInitThunk
0x774B9D42 [ntdll]: (filename not available): RtlInitializeExceptionChain
0x774B9D15 [ntdll]: (filename not available): RtlInitializeExceptionChain

Edit #3

And apparently dials won't work with .DDSs. Any way to fix that? My DDSs are approx. 1/2 the size of my TGAs, would be nice to have that size advantage.
 
What does road noise do exactly? Does it only influence force feedback, or does it have any play in the surface to wheel dynamics? As I understand it, it only influences FF.
I've been thinking about the 'realistic smoke' thread elsewhere, where I commented that maybe the smoke is very uniform unlike IRL where it is a lot more random. I think this is because the surfaces we drive on are uniform, i.e. we use a constant average value for the grip of a surface, whereas IRL the grip varies along the surface.
If road noise influenced the surface grip the same way it does for FF, maybe it would help the smoke, and generally be a closer to realistic simulation of surfaces.

Hi David, it's not the road causing the smoke problems try this...
http://www.racedepartment.com/racer-physics-technical/46919-realistic-smoke-3.html#post724220

Alex Forbin
 
Can we have an audio setting to enable/disable sample looping? e.g. IRL when u drive over a drain cover/grate or manhole cover (how is it when we can fly in the air, put people on the moon, use nuclear energy etc, but we are incapable of making a manhole cover that fits properly?) it makes that clank sound, but if u stop on it, it doesn't continually 'clank'.

Yes Alex that looks far better, and with Mitch's soft particles, looks like we we have fire.
 
...And apparently dials won't work with .DDS...

Same for particles.

Tue Jan 25 13:30:56 (FATAL): [racer/2484] Exception 0xC0000005, flags 0, Address 0x7C9469AA
(this dialog text is stored in QLOG.txt)

OS-Version: 5.1.2600 (Service Pack 3) 0x100-0x1

0x7C9469AA [ntdll]: (filename not available): wtol
0x0055718B f:\dd\vctools\crt_bld\self_x86\crt\src\malloc.c (line 163): malloc()
0x0055B229 f:\dd\vctools\crt_bld\self_x86\crt\src\crtheap.c (line 44): _malloc_crt()
0x0056C45B f:\dd\vctools\crt_bld\self_x86\crt\src\_getbuf.c (line 58): _getbuf()
0x00567F32 f:\dd\vctools\crt_bld\self_x86\crt\src\_filbuf.c (line 125): _filbuf()
0x00556792 f:\dd\vctools\crt_bld\self_x86\crt\src\fread.c (line 268): _fread_nolock_s()
0x005568AA f:\dd\vctools\crt_bld\self_x86\crt\src\fread.c (line 109): fread_s()
0x005568E3 f:\dd\vctools\crt_bld\self_x86\crt\src\fread.c (line 303): fread()
0x00502A2D d:\source\trunk\dev\src\libs\qlib\qfile.cpp (line 115): QFile::QFile()
0x004F353A d:\source\trunk\dev\src\libs\qlib\qinfo.cpp (line 309): QInfo::Read()
0x005B6D3E [racer]: (filename not available): _getch
 
Can we have an audio setting to enable/disable sample looping? e.g. IRL when u drive over a drain cover/grate or manhole cover (how is it when we can fly in the air, put people on the moon, use nuclear energy etc, but we are incapable of making a manhole cover that fits properly?) it makes that clank sound, but if u stop on it, it doesn't continually 'clank'.

Yes Alex that looks far better, and with Mitch's soft particles, looks like we we have fire.

LOL, true. I'm glad you brought up the sound looping. This is also a problem when starting the car, if you don't start immediately the starter sound will loop, if you make the sample long enough to cover the possibility of cranking the engine for a while the whole sample will play no matter how long it is.


Thanks. :) I hope we also get exhaust particles enabled as well.

Alex Forbin
 
Ruud, are you sure that your DDS loader is working properly?
Here's what my image alpha looks like in Photoshop:
DDS.jpg

And here it is in-game:
in-game DDS.jpg


In-fact...it's almost as if it's loading this LOD
wheelLOD.jpg

Instead of the lod0.
 
This problem looks familiar, it has something to do with the encoding/decoding of the DDS files. This is what I remember Ruud told me (Correct me if I'm wrong), internally these files are saved in strips of 4 pixels and then mirrored horizontally for some reason. Sometimes if the files isn't saved correctly these pixels would be mirrored wrong, with the end result being sort of blurred edges.

In what format did you save your DDS? DXT5/DXT3?

You could try to re-save your texture to DXT5, this normally fixes my problems

Hope this helps in some way
 
DXT5 with interpolated alpha is lossy, more so in the mipmaps, you get really bad transparrency using it. Transparrency channes ideally need no loss due to what they are doing.

DXT3 with explicit alpha looks great in PS, even the mips work fantastically, so it all works fine, but you get this weird corruption effect when Racer uses them, like vertical melt-throughs all over the transparrency map.


I could provide pictures, but it's glaringly obvious to anyone who tries a simple object like a tree with DXT5 and DXT3 side by side, vs a TGA!

DXT5, blurry and lossy edge alpha quality, DXT3, good edge quality, looks fine in PS, but Racer renders it with weird melty lines all over it, and TGA is just perfect in every way (but bigger in memory)


DXT3 is the ideal one to use for a DDS that needs a good quality alpha channel (almost all uses really), just it's got this weird corruption melty issue.


Dave
 
Well.. replays are working great! :tongue: This how mine came out.. the hue just continued cycling. Weird. Also, there was a 32mb audio file with no audio..

77798257.png
 
I got interested in surface friction, and googed up some info. I found this page http://www.physlink.com/education/askexperts/ae139.cfm with a list of materials and friction coefficients.
What I found more interesting was this statement
Coefficients of friction must be given for two materials, not one.
Therefore there is no coefficient of friction for steel for example. There is a
coefficient of friction for 'steel on steel'. If we think this way it is not
realistic to have all coefficients of frictions for all material pairs listed.
This statement would imply that Racer uses a very simplistic friction model?
 

Latest News

Are you buying car setups?

  • Yes

  • No


Results are only viewable after voting.
Back
Top