Racer v0.8.35 released

[Ruud]

After quite some time, here's an update. Still needs things worked out before v0.9 though.
Get it at http://www.mediafire.com/file/1kyapoz4xmbnnlh/racer0.8.35.7z

As for changes between this version and an upcoming v0.9, I expect only the audio pitch_scale to possibly change a bit in behavior (if at all), other than that the graphics are not likely to change anymore. I might have called this one v0.9.0RC1 but there's a few bugs (in Config.exe, and the menu selections) that are not too pretty (I need to remove some non-working items).

Notes:
- It uses the Lambo from Mr Whippy; I might not have had the latest version; this one gives a brake balance warning currently (admittedly a new feature)
- Next week I'll try and make a list of the things I still want to do for v0.9.

The changes:
- Pacejka window appeared single buffered in Windows XP, resulting in flickering.
- Added 2 pages to ^9 (telemetry) debug view; all possible and actually used view variables
- Added 'surface' group to logging (ASCII/RTD) with world surface intersection coordinates for all wheels (used internally for laser-scanned tracks).
- RTD logging of orientation is now done in Yaw/Pitch/Roll instead of the car rotation quaternion
- Timing has been restructured - only the multiplayer server now keeps track of time, to sync laptimes across multiplayer.
- Added 'fps on' and 'fps off' console commands.
- Added 'view <n>' command to set the view (normally changed with F1)
- Added the start of a 'system' of parameters & signals, which will give inside info on all kinds of parts. This will be useful
for external tweaking tools, and also internal ones. A generalized way to access parameters. Currently the tree is very
limited, and no external tools are available yet to tweak.
- Added 'system export' commands to export the system tree to an HTML file. Racer will open the HTML file after creation.
See also http://www.racer.nl/tutorial/system.htm
- Added 'set <path> <value>' to set a parameter in the system.
- Added 'get <path>' to get float parameter in the system.
- The 'graph' command now also accepts any parameter in the system; i.e. 'graph step 0 600 car0.engine.rotation_vel'
- Added 'camera <n>' command to switch cameras using a console command.
- Added 'fov <f>' command to set camera FOV directly.
- Added power steering curves for assist/friction/damping/spring (spring only for high-end platforms)
- Curved can now also offset all points
- GPLex dropped for now.
- Added alpha version of 3DS Max exporter (see max/ directory)

Enjoy!

 

[Ruud]

Hey Ruud, thanks for the new version!

Looking forward to getting dirty with it all today, I'm sure you're looking forward to the rest of the barrage of questions about to hit you.

Just quickly to clarify (since it doesn't actually say in the docs) in the tree (as I'm calling it...The PSystem export or whatever it's called) signals are simply readouts of what's currently happening correct? i.e. the downforce being created by a wing. That stuff we wouldn't really want to change anyway - we just change parameters?

Cool.
The tree isn't as extensive as I thought it'd be. Perhaps it's just the Lambo?

Looking forward to digging in. Just a quick thought, since 'system export' opens a webpage and switches windows wouldn't it be better to pause the engine straight after the export? What if you would like to have a readout while doing 300km/h? Sounds like a recipe for disaster to me lol

Thanks!

The system tree will grow in time, I just needed it for a type of live setup tool, where you want a lot of flexibility (this is in our Pro version, it would be possible to create your own and just pass commands to Racer's console to adjust system parameters). I had model parameters working for a moment (live translating of the driver 3D model for example) but that give some problems.

The parameters are indeed things you'd tweak, the signals are more read-only, though sometimes the difference is subtle. What it needs is a tool where you can walk through the tree, and catch signal values more nicely, being able to graph things, and tweak parameter values directly. That doesn't exist yet though.

I've added a pause when 'system export' is executed.

Note that all systems kind of look alike; the Lambo won't be too different from other cars, depending on differential type, number of wings and such.

 

[Ruud]

Note btw that v0.8.35 seems to define cameras relative to the CG, instead of the nullpoint. This is fixed in v0.8.36 but unfortunately it affects all camera locations (need to be offset by the CG offset). Dave is ofcourse in the clear having CG at (0,0,0) ;-) but there are a bunch of cars moving CG away from (0,0,0). Those cameras will then be off a bit.

 

[Ruud]

It's support for rotaional axis different from those that use the vehicle centerline. In particular the hillman imp which I posted in the car thread as a wip. It's been a wip since about 2005 as I can't get the outside front wheel to lift off the ground in a turn as the real car will do. With the rotation of the trailing link the wheel lifts but then bunces up/down. Won't stay up. The file I posted doesn't have the generic suspension but I do have one that does.

Could you mail me that car (with generic suspension going bad)? One of the reasons it's taking so long is that I would have to try and recreate what would possibly be the problem. It's easier to start from your content...

 

[Ruud]

What car is it you are working on anyway Boomer? I keep thinking about a really decent modern F1 race car, but I'm just not sure if the current Racer 'visual' suspension stuff is up to it!? Is it just suspensions with rotations off the cars roll axis that we can't do currently

For an F1-style car it won't do much; suspension movement vertically is under 1cm, these springs are quite stiff. ;-)

 

[Ruud]

Tried to make some cones/brake markers moveables with tracked according to the instructions dated June 5, 2011 which states that the flag= will be 1024.

It was flags=1030!!!!! Now that's a bug! Also throws a Qlog error!!! Needs fixing.

Hm, the flags are bits added together; 1030=1024+4+2, meaning movable, collidable and surface. Alas, it's not Grand Theft Auto, and you can't really drive the wheels over movables, so collidable and surface don't make sense really. You should be able to reduce it to just 1024.

 

[Ruud]

yep Dave, for me too...:frown:

Working on the FPS problem for movables with Julio from Newton. The initial freezing of movables makes the objects never sleep; a bug in Newton 2.34 it seems (using 2.29 mostly now). If I turn off freezing, it works ok (after a second or so, all cones go to sleep and fps is high again). Julio will make a fix so I can initially freeze the objects (immediately sleeping), releasing them as they get hit.
Currently every frozen movable keeps triggering AABB overlap callbacks which is making things slow...

 

[Ruud]

Anyone figure out how to get rid of that"multiview" problem I posted above?

Does anyone else get that Qlog error?

Seems fixed in v0.8.36; not that it was too important, but it could be perceived as annoying. ;-)

 

[KS95]

..And breathe!

 

[M1tch]

How about that

 

[Stereo]

I've added 'get focus car' to v0.8.36. I guess all 3 variants have their merits.

Cheers, I appreciate it. Should make working out what traffic is doing a smidge easier.

 

[camsinny]

Hahaha, thanks Ruud!
Hope people stop pestering you for a while now!

 

[Alex Forbin]

I'm not too happy with it atm, UV mapping discontinuities. And you need a gfxcard capable of reading textures in the vertex shader as well, to limit deformation per vertex. In short, this has to come later...

NP, It's cool that you're working on it and I'm glad you're not just taking the easy way out. If there's anything I can help with in the way of research/modeling etc. just let me know.

Do you have a video card you're recommending right now? I'm thinking of upgrading some of my systems.

Alex Forbin

 

[Stereo]

Do you have a video card you're recommending right now?

My GeForce 460GTX runs the game smoothly, and is able to run the damage shaders ok - although I don't know how to reference the automatically generated deformation texture, if there is one (but using a static one is working). I'd imagine the 450+ and 550+ models are all pretty much okay, not sure what's got the best performance for money right now.

The only thought I had in that direction is a cubemap of geometry deformations, run from the nullpoint - when the car's bounding box hits an object, project the position of the collision into a direction, paint a dent onto the cubemap, and then do the same transform in the fragment shader to figure out geometry coordinate changes, rather than using UV mapping. If you render the colliding object's bound as a depthmap, you even get bumps the same shape as whatever you ran into, roughly. With 4 channels you could technically have 3d offsets + the current red channel 'damage' that tells it when to switch out textures, but I'm not sure how you'd go about figuring out an appropriate 3d movement for damage.
The problem with doing it that way of course is that you'd get cones of deformation traveling all the way back to the center of the car, which might look a little odd depending which textures have damage mapping enabled.

 

[boomer541]

Thanks Ruud! That was a mouthful and a half.

 

[camsinny]

That's what she said!

Sorry to be a bother Ruud, but I seem to have mentioned it in a different thread (i think?)
Any chance of passing a 2nd set of uv coords through? i.e. change the current UVs to a float4 and throw 2nd map channel in .zw

Or is it that the DOF format doesn't support 2 UV sets?

 

[skybh]

That's what she said!

Sorry to be a bother Ruud, but I seem to have mentioned it in a different thread (i think?)
Any chance of passing a 2nd set of uv coords through? i.e. change the current UVs to a float4 and throw 2nd map channel in .zw

Or is it that the DOF format doesn't support 2 UV sets?

Nice suggestion for a lot of things !
We could make some dirt like GT4 for exemple
About the dommages i think the best way is to make them in 3D, but i don't think it's necessary yet..

 

[Some1]

I have a question regarding shadows - can we specify shadow models to use during the shadow map rendering pass? I think it would be rather good for performance to use a lower poly model for shadows instead of using a potentionally 20k+ poly renderable model?

 

[Mr Whippy]

I thought CSM was complexity independent. Not sure though!?

 

[Some1]

I thought CSM was complexity independent. Not sure though!?

Well, for the shadows you still need to render the depth buffer from the light (sun) point of view.

GT5 for example, uses low poly models for shadows, if you look carefully.

 

[Mr Whippy]

I have no idea how GT5 really does it. I'd question the logic of them having special models for shadows.

Perhaps they use an LOD model of the car for the shadows?

Dave