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]

Ie:

http://thumbsnap.com/vyV1WS5Q

The edge there really isn't so hot, the kerb texture is higher quality, with sand bleed, and then the texture it pushes up to is much lower resolution. But in practice you'd never really spot that except in a zero blur screen grab like that, and I'd be happy with that.

We can worry too much about the details and forget the overall quality of the composition.

In my view, just using a diffuse and alpha for transparency if needed, and then a bump map with alpha for specular is plenty for most track materials. Maybe a detail texture on top for extra quality if you want.

If the environment is rich enough with details in the right places, and we have some motion blur, then the details that are wrong will be corrected by our eyes/brains anyway...

ie, an X tree at 50m away looks like a tree, thus why bother with much else for trees 50m or more away?

Kerb/track > soil/grass transitions are hardly visible except when just a few metres away at a standstill, so why bother with much more than a sharp transition, maybe with an overlay poly strip with a 'blend' to cover the seam on a 20m LOD or something?

Hmmm

Dave

I agree with Dave here.

I occasionally feel that the community is too demanding, we want all kinds of nifty features and effects, but the underlying issues and the already-implemented-but-still-buggy features get no attention.

Nowadays, you can have 3d grass (hehe, although a nice new feature could perhaps be a dynamic 3d grass, like Test Drive Unlimited used to do) and lots of vegetation that will hide away the track surface most time. So why bother with tricky shaders?

 

[DavidI]

I agree with Dave here.

I occasionally feel that the community is too demanding, we want all kinds of nifty features and effects, but the underlying issues and the already-implemented-but-still-buggy features get no attention.

Nowadays, you can have 3d grass (hehe, although a nice new feature could perhaps be a dynamic 3d grass, like Test Drive Unlimited used to do) and lots of vegetation that will hide away the track surface most time. So why bother with tricky shaders?

Because putting 3d grass on a hill in the far distance is wasteful, yet a tiled texture on same looks 'tiled'. I was actually suggesting I write it myself, which I will when I need it.

 

[Mr Whippy]

But if we use detail textures we can break repeating textures up. Or if we quad the hill down, we can use a variety of tiling textures arranged in random order to break up the repeating patter, AND a detail texture.

The blend method you mentioned is a good idea if you think you can't achieve what you need any other way.

Ultimately my point was that we can simply worry too much. I do hehe. That is why I hardly ever release any of my own work

I need to start just being realistic about stuff and getting it released instead. That Forza 4 screenie would have me worrying if it were my personal project hehe, but clearly the guys at Turn 10 were happy because it was 'good enough'

I've got loads of 'edges' to do on my current track project and I'd planned a special shader etc etc, but in the end I'm just gonna do something simple because ultimately it'll look almost as good almost all the time!

Dave

 

[Stereo]

On non-repetition of tiling textures... I finally debugged my Wang Tiling shader code (oops, had Y axis mirrored). Don't remember the source link for the shader implementation anymore, it's using a simpler set with only 2 colours iirc.

What this basically does is have a 4x4 library of tiling textures, and a 128x128 control map that says which of the 16 to use. As a result, it repeats 1/32 as often as the base texture. Although there's still a certain repetitiveness along the main X, Y directions. It'd be less obvious with a less contrasty base texture.

I don't know of any code to actually produce the Wang tile textures though, as you can see on Wikipedia they have very specific edge-matching requirements. I grabbed the field of pink flowers from a paper describing it.


This technique, as far as I can tell, makes no difference in framerate compared to standard_f.cg. The 128x128 control texture is not a big load, and fragment shader code isn't a slow point anyway.


The one problem I am having is that mode=linear trashes red/blue channels on the texture though. I had to use green and alpha to get this to work.

 

[frank11]

On non-repetition of tiling textures... I finally debugged my Wang Tiling shader code (oops, had Y axis mirrored). Don't remember the source link for the shader implementation anymore, it's using a simpler set with only 2 colours iirc.

Hello!


This is very usefull, can you please post the shaders and explain how to use them?

Also if you have any idea how to do something similar for the road edge please let us know. I use a texture to blend asphalt to grass, but repeating pattern is just too obvious.


Thanks for all your hard work, Frank

 

[Stereo]

I've put a quick explanation on my website, I haven't had time to bring the .cg code to 0.8.38 yet, but it should be enough to get started.

I'm thinking of writing my longer posts directly on my website in future so they're easier for me to find later, good idea? Doesn't matter?

 

[radome]

I've put a quick explanation on my website, I haven't had time to bring the .cg code to 0.8.38 yet, but it should be enough to get started.

I'm thinking of writing my longer posts directly on my website in future so they're easier for me to find later, good idea? Doesn't matter?

Over in Physics and Technical -> Sand and Grass thread...

I don't know of any code to actually produce the Wang tile textures though, as you can see on Wikipedia they have very specific edge-matching requirements. I grabbed the field of pink flowers from a paper describing it.

Post #9 talks about creating the set of wangtiles.

 

[DavidI]

I've put a quick explanation on my website, I haven't had time to bring the .cg code to 0.8.38 yet, but it should be enough to get started.

I tried the wangtile shader on Mugello, I get flowers with different regions, but they aren't seamless, its like it is mixing up which edges are supposed to match. Any idea's why?

 

[Stereo]

I haven't tried the code on all positive/negative x/z coordinates, it's possible that the code only works right in one quadrant. Depends how cg frac works, unfortunately the reference implementation is cyclical (frac(v) = v-floor(v), floor(v) = v-frac(v) - it's all there in the documentation). I don't see anywhere it goes wrong on Carlswood though.

The index texture is what controls things being seamless, if something's going wrong with that then the tiles won't match up.

There's a line in the cg file:

  //baseCol= whichTile.wyzz*0.5 + 0.5*baseCol;

Uncommenting it should give you something like this.

Which is the index texture, overlaid, slightly swizzled (I'm using W and Y for the main content, z is just filler). For the one I included in the example, it'll show up the same as in the picture.

If the pixels aren't sharp-edged, or, if you look closely at regions of a single colour (like the green in the foreground) and those parts aren't tiling a single square, then something's gone wrong in the cg code.

GIMP makes it a pain in the ass to duplicate the exact colours here or I'd suggest comparing a birds-eye view with the texture.

If it's consistently wrong, except in sections where there's a single colour tile, you could try mirroring the index texture. The first one I had was flipped horizontally, resulting in one direction matching up, the other being wrong. The index texture isn't really random - it's designed so that adjacent pixels' edges match up, but only if tiles are assembled facing a certain way.

 

[DavidI]

I flipped the wangindex horizontally, and that fixed some of it, flipping it vertically fixed the rest. Thanks.
Only problem I have with it is the texture shimmers in the distance, like it's z-fighting or actually moving randomly a few pixels.

I also found this page http://the-art-of-rws.blogspot.com.au/2010/06/wang-part-3.html which describes how to make wang tile textures easily.

 

[Stereo]

I think the shimmer might be insufficient mipmapping. I hadn't really tweaked that much, it did crawl a bit when I was looking at it.

  float2 tileScaledTex = mappingAddress * 0.25f;

I don't know if all GPUs support tex2D(map,uv,ddx,ddy) but this made it look ok for me.

And I just realized what I did wrong... I left Carlswood on standard_f.cg when I was trying to check if the index map was correct, so I've uploaded one that's wrong on both axes.

I changed both these in the files on my site, think I'll make some graphics in line with that page's tutorial.

 

[Mr Whippy]

Ah good old Wang Tiles again

I still think if you are making content for v0.9 onwards kinda poly levels, you really have a lot more flexibility in how you author stuff.

Ie, I essentially did Wang Tiling on my runway, but it's done manually and with lots of quads in the mesh. In practice it does the same thing I guess from a visual point of view, but having all those verts means I can add bumpiness to the driving surface, maybe some vert colouring/shading and so on...


Not saying one way or the other is better or worse, just lots of ways to get the same final looking result


Has anyone else here done Wang Tiles "manually" for general terrain areas? I'm almost totally bought into the idea for one of my tracks, trying to get all the main 'terrain' textures into one 2048x2048 and then mapping them appropriately

I generally find that the Wang Tile method gets you nice looking overall terrain texturing, but we still miss having higher density topographical features... throwing in more quads gets you nicer rolling terrain and ultimately nicer shaped silhouetting.

Dave

 

[camsinny]

Does the CTR exporter not currently export vert colours?
I'm trying to use a shader that uses them but everything seems to be dark rather than white or coloured as I want.

 

[Mr Whippy]

I'm not sure, but I think I had issues with it.

Just make sure Max is actually burning them in the first instance, often you can see them in Max but they are not laid down into the appropriate field when it comes to ASE exports at least... the CTR may well be picking up the same info the ASE > DOF (in modeller) was using.
I had some headaches back in 2004 ish with vertex shading on my track.

Ummm, also, why not try Some1's tool, I'm pretty sure he said he'd added vert colour info support!?

Dave

 

[camsinny]

Good point.
I sort of wanted to use CTR as I assume it should be the norm now. However I want to use VC to colour stuff without using extra maps where they're not needed.
Forgot about some1's tool, thanks!

ARRRGGGGGGGHHHHHHHHGFADJHGASFLKJHEFLKJh
No, both mine and some1's geometry.ini tools make racer think there's no collision flags even though clearly all collide-able objects have flags=6.
And I can't use the geometry.ini that CTR generates because it makes stupid object names. Why the hell does it rename stuff anyway? Part of working inside Max includes proper object naming and naming conventions. You shouldn't have duplicate names, unnamed objects or any meshes named "box01" anyway so why have a stupid feature that renames objects to include the material they have applied?!?!

I can't create content if the tools don't work. CTR needs vertex colour exporting or racer needs to realise that I have in fact got SURFACE on objects.
For reference here's the crash that happens:

Fri Feb 10 18:40:05 (INFO): [racer/3272] --- application start ---
Fri Feb 10 18:40:05 (INFO): [racer/3272] Racer version: 0.8.38 (Jan  6 2012/17:49:09) - customer: Internet
Fri Feb 10 18:40:07 (INFO): [racer/3272] Physics engine: NEWTON v3.0, architecture 2
Fri Feb 10 18:40:07 (INFO): [racer/3272] Safety changed to: SAFE
Fri Feb 10 18:40:10 (INFO): [racer/3272] Loading track 'QR'
Fri Feb 10 18:40:10 (WARN): [racer/3272] Track contains no trackcams!
Fri Feb 10 18:40:10 (WARN): [racer/3272] tcam.cam0.zoom_edge may not be 0; correcting to 10
Fri Feb 10 18:40:10 (WARN): [racer/3272] tcam.cam0.zoom_close may not be 0; correcting to 10
Fri Feb 10 18:40:10 (WARN): [racer/3272] tcam.cam0.zoom_far may not be 0; correcting to 10
Fri Feb 10 18:40:12 (WARN): [racer/3272] Shader skin0/data/tracks/qr/qr_invis_walls: no layers defined (need layer0.map)
Fri Feb 10 18:40:12 (WARN): [racer/3272] QInfo: can't open 'data/tracks/QR/geometry.ini'
Fri Feb 10 18:40:12 (WARN): [racer/3272] No surfaces found that match pattern '*'
Fri Feb 10 18:40:12 (WARN): [racer/3272] No surfaces found that match pattern 'gravel*'
Fri Feb 10 18:40:12 (WARN): [racer/3272] No surfaces found that match pattern 'terr*'
Fri Feb 10 18:40:12 (WARN): [racer/3272] No surfaces found that match pattern 'rumble*'
Fri Feb 10 18:40:15 (FATAL): [racer/3272] None of the track's nodes in geometry.ini have the SURFACE flag; nothing to collide; cars get stuck in Newton!
Remedy: set surface flag (4) in geometry.ini, delete the track's cache directory and try again.
Fri Feb 10 18:40:15 (INFO): [racer/3272] Crash detected - attempting to recover some data before displaying the crash dialog
Fri Feb 10 18:40:16 (FATAL): [racer/3272] Exception 0xC0000005, flags 0, Address 0x004161D2
(this dialog text is stored in QLOG.txt)
 
OS-Version: 6.1.7600 () 0x100-0x1
 
0x004161D2 [racer]: (filename not available): (function-name not available)

And here's my geometry.ini:

objects
{
QR_Track_03
{
file=QR_Track_03.dof
flags=6
}
QR_Track_01
{
file=QR_Track_01.dof
flags=6
}
QR_Terrain_01
{
file=QR_Terrain_01.dof
flags=6
}
QR_Terrain_04
{
file=QR_Terrain_04.dof
flags=6
}
QR_Track_02
{
file=QR_Track_02.dof
flags=6
}
QR_Terrain_02
{
file=QR_Terrain_02.dof
flags=6
}
QR_Terrain_05
{
file=QR_Terrain_05.dof
flags=6
}
QR_Pits_01
{
file=QR_Pits_01.dof
flags=6
}
QR_Terrain_03
{
file=QR_Terrain_03.dof
flags=6
}
QR_Pit_Building_01
{
file=QR_Pit_Building_01.dof
flags=6
}
QR_Pit_Building_02
{
file=QR_Pit_Building_02.dof
flags=6
}
QR_Pits_02
{
file=QR_Pits_02.dof
flags=6
}
QR_Pits_03
{
file=QR_Pits_03.dof
flags=6
}
QR_Terrain_09
{
file=QR_Terrain_09.dof
flags=6
}
QR_Terrain_06
{
file=QR_Terrain_06.dof
flags=6
}
QR_Outer_Terrain_01
{
file=QR_Outer_Terrain_01.dof
flags=6
}
QR_Terrain_08
{
file=QR_Terrain_08.dof
flags=6
}
QR_Sand_Traps_01
{
file=QR_Sand_Traps_01.dof
flags=6
}
QR_Terrain_07
{
file=QR_Terrain_07.dof
flags=6
}
QR_Outer_Terrain_02
{
file=QR_Outer_Terrain_02.dof
flags=6
}
QR_Linemarkings_01
{
file=QR_Linemarkings_01.dof
flags=6
}
QR_Linemarkings_03
{
file=QR_Linemarkings_03.dof
flags=6
}
QR_Linemarkings_02
{
file=QR_Linemarkings_02.dof
flags=6
}
QR_Terrain_10
{
file=QR_Terrain_10.dof
flags=6
}
QR_StartFinish_01
{
file=QR_StartFinish_01.dof
flags=6
}
QR_BikeGridBox_39
{
file=QR_BikeGridBox_39.dof
flags=6
}
QR_BikeGridBox_36
{
file=QR_BikeGridBox_36.dof
flags=6
}
QR_BikeGridBox_37
{
file=QR_BikeGridBox_37.dof
flags=6
}
QR_BikeGridBox_38
{
file=QR_BikeGridBox_38.dof
flags=6
}
QR_BikeGridBox_35
{
file=QR_BikeGridBox_35.dof
flags=6
}
QR_BikeGridBox_34
{
file=QR_BikeGridBox_34.dof
flags=6
}
QR_BikeGridBox_29
{
file=QR_BikeGridBox_29.dof
flags=6
}
QR_BikeGridBox_30
{
file=QR_BikeGridBox_30.dof
flags=6
}
QR_BikeGridBox_31
{
file=QR_BikeGridBox_31.dof
flags=6
}
QR_BikeGridBox_32
{
file=QR_BikeGridBox_32.dof
flags=6
}
QR_BikeGridBox_28
{
file=QR_BikeGridBox_28.dof
flags=6
}
QR_BikeGridBox_33
{
file=QR_BikeGridBox_33.dof
flags=6
}
QR_BikeGridBox_27
{
file=QR_BikeGridBox_27.dof
flags=6
}
QR_BikeGridBox_20
{
file=QR_BikeGridBox_20.dof
flags=6
}
QR_BikeGridBox_21
{
file=QR_BikeGridBox_21.dof
flags=6
}
QR_BikeGridBox_22
{
file=QR_BikeGridBox_22.dof
flags=6
}
QR_BikeGridBox_23
{
file=QR_BikeGridBox_23.dof
flags=6
}
QR_BikeGridBox_24
{
file=QR_BikeGridBox_24.dof
flags=6
}
QR_BikeGridBox_25
{
file=QR_BikeGridBox_25.dof
flags=6
}
QR_BikeGridBox_26
{
file=QR_BikeGridBox_26.dof
flags=6
}
QR_BikeGridBox_17
{
file=QR_BikeGridBox_17.dof
flags=6
}
QR_BikeGridBox_15
{
file=QR_BikeGridBox_15.dof
flags=6
}
QR_BikeGridBox_16
{
file=QR_BikeGridBox_16.dof
flags=6
}
QR_BikeGridBox_18
{
file=QR_BikeGridBox_18.dof
flags=6
}
QR_BikeGridBox_13
{
file=QR_BikeGridBox_13.dof
flags=6
}
QR_BikeGridBox_14
{
file=QR_BikeGridBox_14.dof
flags=6
}
QR_BikeGridBox_19
{
file=QR_BikeGridBox_19.dof
flags=6
}
QR_BikeGridBox_12
{
file=QR_BikeGridBox_12.dof
flags=6
}
QR_BikeGridBox_10
{
file=QR_BikeGridBox_10.dof
flags=6
}
QR_BikeGridBox_08
{
file=QR_BikeGridBox_08.dof
flags=6
}
QR_BikeGridBox_09
{
file=QR_BikeGridBox_09.dof
flags=6
}
QR_BikeGridBox_11
{
file=QR_BikeGridBox_11.dof
flags=6
}
QR_BikeGridBox_06
{
file=QR_BikeGridBox_06.dof
flags=6
}
QR_BikeGridBox_04
{
file=QR_BikeGridBox_04.dof
flags=6
}
QR_BikeGridBox_07
{
file=QR_BikeGridBox_07.dof
flags=6
}
QR_BikeGridBox_05
{
file=QR_BikeGridBox_05.dof
flags=6
}
QR_BikeGridBox_02
{
file=QR_BikeGridBox_02.dof
flags=6
}
QR_BikeGridBox_00
{
file=QR_BikeGridBox_00.dof
flags=6
}
QR_BikeGridBox_01
{
file=QR_BikeGridBox_01.dof
flags=6
}
QR_BikeGridBox_03
{
file=QR_BikeGridBox_03.dof
flags=6
}
QR_GridBox_01
{
file=QR_GridBox_01.dof
flags=6
}
QR_GridBox_02
{
file=QR_GridBox_02.dof
flags=6
}
QR_GridBox_00
{
file=QR_GridBox_00.dof
flags=6
}
QR_GridBox_03
{
file=QR_GridBox_03.dof
flags=6
}
QR_GridBox_04
{
file=QR_GridBox_04.dof
flags=6
}
QR_GridBox_05
{
file=QR_GridBox_05.dof
flags=6
}
QR_GridBox_06
{
file=QR_GridBox_06.dof
flags=6
}
QR_GridBox_07
{
file=QR_GridBox_07.dof
flags=6
}
QR_GridBox_08
{
file=QR_GridBox_08.dof
flags=6
}
QR_GridBox_09
{
file=QR_GridBox_09.dof
flags=6
}
QR_GridBox_10
{
file=QR_GridBox_10.dof
flags=6
}
QR_GridBox_11
{
file=QR_GridBox_11.dof
flags=6
}
QR_GridBox_12
{
file=QR_GridBox_12.dof
flags=6
}
QR_GridBox_13
{
file=QR_GridBox_13.dof
flags=6
}
QR_GridBox_14
{
file=QR_GridBox_14.dof
flags=6
}
QR_GridBox_15
{
file=QR_GridBox_15.dof
flags=6
}
QR_GridBox_16
{
file=QR_GridBox_16.dof
flags=6
}
QR_GridBox_17
{
file=QR_GridBox_17.dof
flags=6
}
QR_GridBox_18
{
file=QR_GridBox_18.dof
flags=6
}
QR_GridBox_19
{
file=QR_GridBox_19.dof
flags=6
}
QR_PitWall_01
{
file=QR_PitWall_01.dof
flags=6
}
QR_Barriers_01
{
file=QR_Barriers_01.dof
flags=6
}
QR_Buildings_02
{
file=QR_Buildings_02.dof
flags=6
}
QR_Buildings_01
{
file=QR_Buildings_01.dof
flags=6
}
QR_Rumble_Strips
{
file=QR_Rumble_Strips.dof
flags=6
}
QR_Invis_Walls_01
{
file=QR_Invis_Walls_01.dof
flags=6
}
QR_Outer_Terrain_04
{
file=QR_Outer_Terrain_04.dof
flags=6
}
QR_Pit_Linemarkings_01
{
file=QR_Pit_Linemarkings_01.dof
flags=6
}
QR_Starters_Tower_01
{
file=QR_Starters_Tower_01.dof
flags=6
}
QR_Decals_01
{
file=QR_Decals_01.dof
flags=6
}
}

The geometry.ini created by CTR:

; Geometry file automatically generated by CTR (Content To Racer) Plugin
 
objects
{
concrete_2_qr_pits_01
{
file=concrete_2_qr_pits_01.dof
flags=6
}
concrete_2_qr_pits_02
{
file=concrete_2_qr_pits_02.dof
flags=6
}
concrete_2_qr_track_01
{
file=concrete_2_qr_track_01.dof
flags=6
}
gravel_trap_0_qr_sand_traps_01
{
file=gravel_trap_0_qr_sand_traps_01.dof
flags=6
}
gravel_trap_1_qr_sand_traps_01
{
file=gravel_trap_1_qr_sand_traps_01.dof
flags=6
}
outer_terrain_0_qr_outer_terrain_01
{
file=outer_terrain_0_qr_outer_terrain_01.dof
flags=0
}
outer_terrain_0_qr_outer_terrain_02
{
file=outer_terrain_0_qr_outer_terrain_02.dof
flags=0
}
outer_terrain_1_qr_terrain_03
{
file=outer_terrain_1_qr_terrain_03.dof
flags=6
}
qr_decals_0_qr_decals_01
{
file=qr_decals_0_qr_decals_01.dof
flags=0
}
}

Had to cut stuff out of the last geom.ini because of a stupid character limit, so please ignore the length inconsistency. It's more about the fact that flags=6 is EXACTLY THE SAME as flags=6. So why the hell doesn't it work?

 

[Alex Forbin]

I assume you deleted the tracks cache folder?

Alex Forbin

 

[camsinny]

Yep.

Or perhaps is the problem that vertex colours just don't work anymore?
Why not?
I have a building with a few different VC's but in racer it just shows up as a really dark grey when I'm only passing the colour through to the outcolor.
What's going on?!?!
Which map channel are vc's stored in?

 

[camsinny]

Also, as you can see wireframe doesn't work in the bottom two cases.

 

[Some1]

Camsinny, did you check the box that says "Vertex Colors" when exporting with my exporter?
Also, did you collapse your vertex color modifier in Max before export?

 

[camsinny]

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.