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.

 

[camsinny]

Weird, it works for me too on SwissStroll (Cg).

Not working on the track I'm developing here. Used Carlswood as a base, though I am using a custom CG shader inside a folder.
That also breaks the wireframe command (or something...)


Custom shader blends between 3 different textures and modifies the world tc's so it doesn't appear to tile as obviously. Uses alpha to determine blending value which is why the shadow appears to blend through the textures.
Ruud, I can send you this track if it helps. Also, what's the best way to get depth in the fragment shader without using a custom vertex shader? I'm after a 0...1 output that I can scale (i.e. i want it to be 0 at the camera and 1 at say, 1000m or 500m - i'd set that in the shader).
I know custom shaders aren't the way to go but I think this is a MUCH better blending shader than the one currently supplied, it allows you to paint a texture for blending between multiple textures which works well.

Also, does anyone else get this?

It shows up in both tracked and in racer proper.

 

[boomer541]

Thanks Some1, I updated my GTX 285 driver to version 6.14.12.8558 (nVidia 285.58) and turned on the mipmaps and all is well.

Ruud, I don't like the tracked colors, ugly. Could you please give us the option of turning them off like we are able to do on so many other things, please, pretty please.

 

[Mr Whippy]

That is an interesting shader Cam.

Not sure what yo are doing there then... is that 3 flat diffuse textures in one shader, no spec/reflect/normal controls? Then just blending with vert colouring? Or another texture?


I personally think the current blend shader works nicely in Racer, if you use it in the right places and the right way around. Ie, map the important stuff, then let the WC stuff be painted in to get your nice edges...
Then have another blend shader from the new edge into that WC part again.

Or, another thing I quite like is to just use decals for certain patches of blending, since you can get things very close and use a sort_offset to get them rendering on top all the time... then you can have two totally unique materials with high quality blending at edges if you want.

But all that said, how important are these details super close? Usually I am tearing along at 50mph+, and with some fs_filter motion blur you won't see half the detail and effort and shader overhead you put into these special areas.

Some scatter object grass, debris, perhaps scattered patches of dust/blend, might be enough. They can run on LOD, disappear after 100m, and cost you nothing, wheras a full-time blend shader is used all the time the geometry of that edge is visible, and costs you.

They also ultimately cost you in control. Ie, one map in the mix you might want normal and spec, the other some reflection map and then another just a spec map and usual diffuse map...
With a mega shader you generally will tend to make a compromise, which looks worse perhaps, than good shaders/materials with little to no blending, or less sophisticated blending...

Go drive on GT5's Le-Mans circuit. There is horrible edge blending on there. Ie, sand to tarmac has no spec on the tarmac bits, while right next to it the proper repeating tarmac does.
However, the general feel is of high quality and immersive driving. At any kind of driving speed with the motion blur working you just don't notice. If you stop and look you can see it's a problem, but it's done so well anyway you don't care really. This is a driving sim/game, not a sand trap blended into asphalt appreciation sim

I agree it's important to push the boundaries, but getting too tied up in details stops you worrying about the overall form/function of what you are making. Something I easily do (makes me release very little), but is something it's good to be able to recognise when you start doing it

Dave

 

[DavidI]

I've done some experimenting with multi-layer blending too, what I haven't experimented with is using shaders vs poly's. What if you make the landscape a reasonable amount of polys, and just use simple shaders to lay down varied materials on the landscape to provide the detail.
Then make a similar sized landscape from maybe 16 poly's,one or two materials and use a complex shader to lay down varying textures.
It'd be interesting to know which is heavier on the GPU.

 

[camsinny]

I'll respond in detail soon, but spec is dealt with in the alpha map of the blended materials.

 

[Mr Whippy]

Well my as yet un-released Elvington uses 4 x 2048x2048 atlases and then a 6mx6m grid covering a huge area. It feels totally random and not repeated textures over the whole area of concrete, old concrete, tarmac variety and tarmac crumbling over concrete.

Generally FPS are super super fast since it's just four shaders for the entire driving surfaces, a few square km that look unique and no repeating feeling as you drive along them.

I think that geometry is kinda irrelevant now, if you are modelling fairly modestly anyway. Going crazy will always be costly but I'm happy to have say 1m grid pattern for a road mesh, so about 4 polys wide and thousands long over 1km... then adding in a few more polygons for kerbs so you get a nice soft profile for driving onto them etc...

Dave

 

[QuadCoreMax]

Well my as yet un-released Elvington uses 4 x 2048x2048 atlases and then a 6mx6m grid covering a huge area. It feels totally random and not repeated textures over the whole area of concrete, old concrete, tarmac variety and tarmac crumbling over concrete.

Cool to see my revealed techniques in action, packaging UVs is a form of art...

Take into account, that you can go even bigger, it works here on my ancient ATI GPU, 4096 x 4096px car custom liveries (~10mb dds format), make sure you enable in racer ini the textures.max_wid/hgt to your max. GPU specs. I imagine some here could set it to 8192 x 8192px

 

[Mr Whippy]

Problem is a small DDS is still BIG in graphics memory.

Atlasing textures just made sense for Elvington because of the type of driving surface. The added issue is that some of them have to tile nicely despite them possibly being randomly placed!

For most stuff packing UV's is best done by software and then have the coords adjusted at export, but I quite like spending time placing stuff in atlases... didn't Quake1 use atlasing, especially for the light maps it baked... probably stuff even before that. Not really a new technique

Technically we are behind here in using them. I'm not sure why most tracks from things like GTR2 and rFactor etc use fragments... hmmmm... possibly was more optimal back in those days?!

Dave

 

[camsinny]

Alright, have a bit of time to reply now:

I remember the technique used on elvington, worked really well for that since the concrete blocks could tile with a nice seam whereas terrain is a bit different.

Or, another thing I quite like is to just use decals for certain patches of blending, since you can get things very close and use a sort_offset to get them rendering on top all the time... then you can have two totally unique materials with high quality blending at edges if you want.

But all that said, how important are these details super close? Usually I am tearing along at 50mph+, and with some fs_filter motion blur you won't see half the detail and effort and shader overhead you put into these special areas.

The idea behind this shader is that it's basically the best of both worlds: there's the higher detailed textures for those wanting to have a bit of a gawk but as you're driving along you have a lovely, smooth transition between 3 different texture types, all in one shader. This way I get away with having ALL the terrain in one shader, one object if I choose - we'll see how that works out. I am however planning on splitting out the gravel/sand traps because the downside of this shader is that (I believe) the surface definitions only work on the bottom layer of a (racer) shader? i.e. currently I have my blendmask texture on layer0, so currently racer thinks I'm on tarmac all the time. Ruud, I noticed on the racer documentation there was something about a subset NYI - anything ever come of that? I can only imagine racer determining which texture the wheel's currently on through a complex shader like this is too difficult, but perhaps letting racer see what's on things other than layer0? (This mightn't even be how it works, I could be doing something wrong! haha)

My theory is that this technique should help FPS just a little through the absence of multiple objects, rendercalls and such through having one big dumb object for terrain (might still need splitting, not sure yet) rather than bother with trying to get some nice details through alpha planes. Though I am going to use them elsewhere...hmmm.

 

[Mr Whippy]

Yeah, materials are an issue.

I had problems there too, on Elvington I wanted you to 'feel' the white painted lines if you hit them, so they are actually flagged to be able to be hit, and lay about 3mm above the surface... they are also shaded appropriately so they don't z-buffer fight badly.

I've also used decals on another track where I wanted to blend between two different terrain shaders, but where the fundamental terrain was the same. Ie, a dusty track with ruts using a normal map, and a detail map, and then a wider dusty terrain map using normal map and a detail map using planar repeating mapping. To get the seam between the two nice needed a 'blend' part which was best done with a strip of polygons with another shader that covered the seam... the alpha map for the seam was fairly ok, but then I added lat/long noise to the verts too, so the edge had even more randomness to it.
I was perfectly happy in the end.


Every need ultimately has a different best approach. I'm just worried that three materials in one is going a touch too far. I'd prefer to cut more into the polygons and make an array of blend 'sections' to map in at appropriate places, then you can have even MORE control and visual quality.
My main problem why I'm not going down the same route as you Cam, is that texture memory is costly, and using lots of it simply to blend large areas together when maybe 90% of the data in there is block colour is a waste
Great when it's 90% defining an edge (as in Ruuds example on Racer.nl), and then you move into a repeating world coord shader, but covering the entire areas to be blended with coverage data just feels wrong to me...

I'm sure that same memory space could be used to fill the areas with better information.

*however* I've not tested all the ideas, so it's cool to see someone doing it, so we can all learn from it
I'm just guessing and theorising a lot of the time...

I'm also sure the technique will have value somewhere for certain tasks, such is the beauty of having choices

Dave

 

[camsinny]

Is there any way for the CTR exporter to just throw an error when an object doesn't have UV's instead of freezing max? That's super annoying.

 

[Ruud]

The cameras are still broken, when using SMD cameras and turning the car, the cameras will pivot around the cars point of origin making you move closer and farther away from the dash.

Ruud here is a camera that demonstrates the effect...

camera0
{
  offset
  {
    x=0.398438
    y=0.9258
    z=-0.2407
  }
  offset_to
  {
    x=0.398438
    y=0.9258
    z=2.407
  }
  src
  {
    mass=5
    k=1150
    damping=695
    maxdist=0.23
  }
  dst
  {
    mass=10
    k=1000
    damping=1000
    maxdist=.0
  }
  model=1
  wheels=0
  view=1
fov=60
  name=driver
}

Alex Forbin

I tried that, but it seems ok (I added the chassis & wheel models to see more clearly). What exactly do you think is the problem with this camera?

 

[Raphael Buthmann]

I tried that, but it seems ok (I added the chassis & wheel models to see more clearly). What exactly do you think is the problem with this camera?

It happens just with cars which cg point is moved via car.ini

 

[Mr Whippy]

I knew all this cofg all stuff offset stuff would come and bite us in the bum

I still set everything so CofG is near as damn it perfect on my models...

 

[Alex Forbin]

I tried that, but it seems ok (I added the chassis & wheel models to see more clearly). What exactly do you think is the problem with this camera?

Turn to the and left the dash gets closer, right and it gets farther away. I notice it more with the interior being visible. I tried RBs idea and set the car.cg.x,y,z offsets to 0,0,0 and still had the effect, but I did not try it with a car with it's model actually moved to the proper CG.
I don't know why it would be any different than setting the car.cg to 0,0,0 however.
I also notice that some cars will make the camera move against the G-forces instead of with them, it's as if the driver is leaning into the curves. It's probably more realistic that way, but I don't know if it is intentional.

Alex Forbin

 

[Alex Forbin]

Another problem I've been having is with generic models. If the CG is moved in car.cg the generic models become offset from the car model. In general the coordinate system seems to be at the root of many evils.

Alex Forbin

 

[camsinny]

Does mipmap_bias not work on normal textures now? Should we be heading toward authoring this solely inside of DDS textures?

 

[QuadCoreMax]

Does mipmap_bias not work on normal textures now? Should we be heading toward authoring this solely inside of DDS textures?

From what I know, correct me, please, if I'm wrong :
1. Yes
2. Yes

About the SMD cameras, IDK, if it's their props or internal to the code, but that example (Alex cam) shows when steering at high velocity, a kind of "stuttering" occurs which isn't that nice.

=========================================
Traffic Cars Envmap Bug ?

Thanks to Mitch, I've successfully tested my 1st traffic cars simulation (1st ever ?), I've noticed the envmap reflections going on, even if the scripted traffic cars aren't moving. I'm using the real live env map (enable=0+ live_track=1 + frames_per_update=2 + render_once=0) generation too.

=========================================
Other Top Secret Discoveries

I found some hidden camera movements, that means the up/down + left/right which aren't shown anywhere in docs.
I suppose, you'll find them as well, with some curiosity !
Assembling all these cameras movements commands & relating them with car props in Racer scripts somehow & we get a real complex head movement simulation or SMD cams behaviors.

I hope, we will get some cameras functions, props & events, so we can materialize more advanced camera scenarios ideas into Racer via scripting. I wish to have something that never generates the same assembled collection of cam interpolated movements (something like disco cams animations), created dynamically / 'on fly'.

Sure, that would mean, no more manual placements in Tracked, i.e. in Freehand, that was kind of annoying task to set ~ + 110 cams.

I think, it's quite easy in the end, if a city layout follows RULES, i.e., my city Freehand is flat, so we know stuff like the Y (height) value is the same all over the city ; we do also know about surfaces types/car interactions & lots of other stuff.

More discussions in the recent Traffic thread.

 

[Some1]

Traffic Cars Envmap Bug ?

Thanks to Mitch, I've successfully tested my 1st traffic cars simulation (1st ever ?), I've noticed the envmap reflections going on, even if the scripted traffic cars aren't moving. I'm using the real live env map (enable=0+ live_track=1 + frames_per_update=2 + render_once=0) generation too.

Perhaps the traffic cars use the player car's envmap? It would be quite costly to render the envmap for each car...

 

[Mr Whippy]

Perhaps the traffic cars use the player car's envmap? It would be quite costly to render the envmap for each car...

This is where localised generated envmaps would be an interesting idea, perhaps at lower resolutions too.

So they are rendered at TOD change or track load!? Then referenced automagically.

Ie, $trackenvmap_local

Used for other cars and traffic, along with buildings glass etc... it's still annoying having buildings with glass reflect what the car is reflecting because we can only reference one envmap (as far as I know), and that is the live car one...

Dave