Racer v0.8.38 released

[Ruud]

Racer v0.8.38 is now available at http://www.mediafire.com/file/a9z1omd6rmhzymb/racer0.8.38b.7z

Enjoy!
Ruud

Changelist:
- Look_up/look_down controls added for to make TrackIR devices possible.
That makes head tracking possible, although currently a bit crude.
- In your controller file you can add global.up_down_velocity to set up/down look velocity (default=250)
- In your controller file you can add global.up_down_look_max to set the max up/down look angle (default=45)
- Removed energy conserving diffuse/specular lighting for version 0.9.
- Auto exposure turned back on. It can cause dips in framerate on some systems (every second, a grab is mipmapped to obtain the scene brightness).
- Added shader .mipmap_bias for the global shader and optionally for separate layers.
- Added cubemap mipmapping to all reflection shaders for environment mapping.
Requires a good graphics card; otherwise, turn off envmap.generate_mipmaps (set to 0).
- Fixed keep_aspect (dials/views.ini) for multi-monitor setups.
- Setting up graphics settings and starting a race would crash.
- Added dev.collisions setting to globally turn off collision checking.
- Wireframe mode gave bad texturing for the rest of the graphics.
- Trackcam FOV clamped to zoom range indicated by the camera
- Newton solver parameters reverted in the hopes of fixing now & then hangups (10-200 seconds each, after several hours of play)
- Car camera offset seems back working; the FIXED camera type should now work correctly again.
- Shadowmapping in car camera mode focuses on the car, even if the camera from/to positions are some distance away from the car.
- Reverted back to FMod 4.30 (was v4.36) since some people had volume problems at startup.
- Differential power_ratio warnings were mistakenly given for non-LSD type diffs.

 

[Some1]

Yeah, vert colours box was checked and collapsed the stack.
Tried it without collapsing the stack too, as well as using the vert colours as per max's face sub-object mode. No dice on all accounts.

Interesting... perhaps something in Racer has changed (DOF format?) since I'm pretty sure the tool used to export vertex colors correctly.

 

[Mr Whippy]

It looks like ASE is passing them... but not properly?!

As said, it's ages since I've messed with these, but I do remember having a lot of issues baking vert colouring to the actual verts which were then passed to Racer... 3DS Max is very bad at actually telling you what it's doing sometimes, it looks right for all Max purposes, but the parsing into Racer is what is important, you need to make sure Max is putting the right info into the verts that are then where the ASE > dof or other tools are looking!


I'll have a fiddle tonight if I get time, and see if I can make it work right

Dave

 

[camsinny]

Figured it out.
For some stupid reason standard_vc_v.cg changed the vertex colours to only be a float instead of float3.
Here it is as it should be:
standard_vc_v.cg

//
// Standard lighting, with vertex color
// Atmosphere & single texture
//
 
#include "atmosphere.cg"
#include "lighting.cg"
 
// App to vertex
struct a2v
{
  float4 Position : POSITION;
  float3 normal  : NORMAL;
  float2 tc0      : TEXCOORD0;
  float3 color    : COLOR;
};
 
// Vertex to pixel shader structure
struct v2p
{
  float4 Position: POSITION;
  float3 FPosition: TEXCOORD4;    // For fragment shader
  float3 color          : COLOR;
  float3 normal        : TEXCOORD5;
  float4 RayleighColor  : TEXCOORD2;
  float4 MieColor      : TEXCOORD3;
  float2 tc0              : TEXCOORD0;
  float3 Direction: TEXCOORD1;
  float  extinction: TEXCOORD6;
};
 
void main(
  // a2v
  in  a2v IN,
  out v2p OUT,
 
  // Constants
  uniform float4x4 modelViewProj,
  //uniform float4x4 modelMatrix,
  uniform float3  lightDirection,
  uniform float3  eyePosW,
  uniform float3  lightColor,
  uniform float    time,
  // Atmosphere
  uniform float    sunIntensity,
  uniform float    atmosRayleigh,
  uniform float    atmosMie,
  uniform float    extinctionFactor
)
{
  // Transform to clipspace
  OUT.Position=mul(modelViewProj,IN.Position);
 
  // Atmosphere
  CalculateAtmosphere(atmosRayleigh,atmosMie,sunIntensity,eyePosW,IN.Position,lightDirection,
    OUT.RayleighColor,OUT.MieColor,OUT.Direction);
 
  // Extinction factor of regular color
  OUT.extinction=CalculateAtmosphereExtinction(OUT.Position,atmosRayleigh,atmosMie,extinctionFactor);
 
  // Pass texcoords and such
  OUT.tc0=IN.tc0;
  OUT.normal=IN.normal; //mul((float3x3)modelMatrix, IN.normal);
  OUT.FPosition=IN.Position.xyz; //mul(modelMatrix,IN.Position).xyz;
  OUT.color=IN.color;
}

Still doesn't really explain why CTR and some1's tool don't export the vc's correctly in the first place. Using illumination channel perhaps? Using ASE > modeler > DOF now anyway.

 

[Scratchi]

Hi

Does this game run natively on Linux or only through Wine? If it runs natively, where can I find the Linux build of the newest version?

Thank you

 

[KS95]

Only through Wine I'm afraid. But it's better than running the outdated Linux version

 

[DavidI]

Ruud, when will we get to try an HLSL version?

 

[Alex Forbin]

Ruud, when will we get to try an HLSL version?

Just so you will know,GLSL is what he's working on.

Alex Forbin

 

[DavidI]

missed it by THAT much...

 

[Ruud]

Interesting... perhaps something in Racer has changed (DOF format?) since I'm pretty sure the tool used to export vertex colors correctly.

No change in the DOF format. With a hex editor, try checking the VCOL chunk; there should be something non-zero in the colors that follow (all floats).

@Camsinny; thanks for finding the float3 bug in standard_vc_v.cg!

An alternative to check out your vertex color itself is to modify data/renderer/shaders/standard_vc_f.cg; at the bottom, add the line to only output the incoming (vertex) color:

 // Mix sky with texture color based on atmospheric influence
  //outColor.rgb=lerp(skyColor,ambientColor+sdColor*lit,IN.extinction);
  outColor.rgb=IN.color*10;

That should give you the color, apart from exposure scaling (HDR->LDR).

 

[boomer541]

Raphael shders has problems that took me a couple of days to track down. I noticed that a car that worked/looked good in ver 0.0834 was dull and bad chrome when using his shaders. Tried a couple of other cars and had the same results. I determined that the only shaders needed for Raphael's great Bugatti from the renderer/shaders folder are:
carbon_f.cg
carbon_v.cg
dyn_standard_bump_reflect_f_carbons.cg
dyn_standard_bump_reflect_f_spec.cg
dyn_standard_bump_reflect_v_carbons.cg
dyn_standard_reflect_f_speccol.cg

Also the Aadiff grass textures for Polish Roads looks good with just the above six files.

Also noted that if you want a texture to reflect you now have to add "reflect= " to the map layer. Possibly other layers.

 

[Raphael Buthmann]

Did you tried the updated version of my shaders ? They only works with racer 0.8.38 because of envmap mipmap D:

 

[Mr Whippy]

The Veyron shaders are nice, but lots have, I think, very unrealistic values in them. Ie, chrome that reflects more brightly than the environment... little details that are not hard to fix, but DO need fixing.

There also seemed to be a lot of them, which as we know costs loads of FPS.

Hmmm

Dave

 

[camsinny]

Custom shaders are a bad idea. Tonemapping is the best way to customise the look of racer without messing with the fundamental lighting model.

Speaking of costing loads of FPS, Ruud, are shaders instanced through the racer.shd? i.e. when we define them at the start of a file are they then instanced each time they're used?

If so would it not be advantageous to create a master shader which does everything then that could be used for each material?
Sure there'd be bumpmap calculations for each material (calculating tangents on everything costs) but would it outweigh the alternative of having 50 different shaders that do 50 unique things?

 

[Mr Whippy]

Problem then is you really do need to atlas, otherwise you would just be running complex shaders on lots of things that don't need complexity.

I think the current system is fine, authors just need to be considering that texture lookups and shader passes cost lots of FPS.

Ergo, keep shader counts low, and keep texture counts low.

There is a happy medium point though, and you can reach that right now with good authoring.

In theory, you should be able to get a car down to about 10-12 shaders I think, and it look amazingly good for most purposes.

Perhaps have a special photomode car/shader file with more shaders/textures if you think it needs them

Dave

 

[boomer541]

Just noticed that using particles (backfire) on the side of a car has the fire a bit too far to the rear when the car is not moving. As the car moves the fire moves to the location specified in the car.ini file. The movement is several cm (about a foot).

Anyone else have this bug?

 

[Cosmo°]

boomer: It seems to be the other way round here; ie, I set up the backfire position standing still with "show carpoints" enabled via console and the animation matches up like this. When the car is moving forward however, a "reversed inertia effect" (for lack of a better expression) moves the position ahead of the yellow indicator, while driving in reverse moves the backfire particle further back.

This happens on both vehicles that have no cg offsets defined in car.ini, as well as those that do (one might think this effect could be related to the ongoing offset related issues).

Apart from moving particles in a counterintuitive direction like this, I don't think they should change position in the first place.

 

[Alex Forbin]

Speaking of particles, has anyone figured out how to make the exhaust work yet?

Alex Forbin

 

[boomer541]

Thanks Cosmo. Looks like Ruud has work to do.

Alex, have you tried scripting?

 

[Alex Forbin]

Thanks Cosmo. Looks like Ruud has work to do.

Alex, have you tried scripting?

No, I figured it MUST work since it's in Racer's default install.
I would still need to ability to control the birthrate ect. by RPM for it to work properly. If Mitch is watching maybe he will look into it.

Alex Forbin

 

[QuadCoreMax]

Thanks Cosmo with the backfires...hope Ruud will fix it !

=============================================
PyRacer Car Editor

I'm building a new Python car editor, which I hope I'll finish soon. My regex algorithms works quite good, need more time to debug with all kinds of car.ini's. If any Python expert is here, let me know...

Also, it might be very useful to pipe Racer with Python, since he's dealing in OOP style with ALL kind of objects...
I saw all kind of interesting modules/classes to implement/use in our Racer projects to increase productivity in less time.

I suppose, if you convert your code source, most of it, to Python, your code would be x2 less bigger than your actual code + x10 more efficient.There's also all the stuff we need for our future, like custom LIDAR & PyOpenGL modules...(Python, GNU...)

I looked also to Quantum Programming (D-Wave), coincidence is, it's using Python custom modules..

Please Ruud, check it out, it could be 1 solution to increase performance on your Racer VM (virtual machine).
I'll probably test it & see if it can help me in complex problems I'm facing (traffic smart logic layout & advanced AI technology)...

It's exactly the purpose of D-Wave, resolving AI problems, so I've been thinking a lot about you & your amazing VM, which I suppose is just the beginning of a new world full of infinite possibilities.