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.

 

[boomer541]

Ruud, it would be far, far better to have shadows and let us decide which shdows to turn off! I have 135 cars and 140 tracks that would require editing the .shd file in each. A real PITB! How about putting shadows back on?

Anyone looked at TrackEd in this version? Models were all yellow when I looked at Early Fall in Norway but the sky was ok. The dky was bad when running it in Racer, See my previous post above.

All the racer utilities need to be checked and fixed!

I may have had a bad download and will try to download it again.

DavidI, My GTX285 is uptodate and had no problems with v. 0.0837.

 

[Alex Forbin]

Anyone looked at TrackEd in this version? Models were all yellow when I looked at Early Fall in Norway but the sky was ok. The dky was bad when running it in Racer, See my previous post above.

All the racer utilities need to be checked and fixed!

I've tried tracked it works fine here. Ruud updated the download in the first post. The only problem I'm having is the sound volume bug.

Alex Forbin

 

[camsinny]

Ruud, it would be far, far better to have shadows and let us decide which shdows to turn off! I have 135 cars and 140 tracks that would require editing the .shd file in each. A real PITB! How about putting shadows back on?

Nope, I disagree. Shadows drain SO MUCH GPU power and most of the time people add shadows for things that don't need it.

Since most content would probably need tweaking for v0.9 anyway I don't see the need. People need to go through shaders and edit them a bit already, adding another line won't be a big issue.

 

[DavidI]

Boomer Early Fall CG version (at least the one I have here) is using its own custom sky shader in the tracks /cg folder

vf_sky
{
  vertex_shader
  {
    file=cg/sky_daynight_v.cg
    ;file=sky_v.cg
  }
  fragment_shader
  {
    file=cg/sky_daynight_f.cg
    ;file=sky_f.cg
  }
}

If i remove the /cg & use the default Racer shaders, the sky works as expected. The tracks sky shaders are incompatible with racer now it would seem.

 

[boomer541]

Got good cars now! they don't glow and the Qlog errors are gone!
The culprit:
; Generate mipmaps from environment map for soft reflection maps? (very expensive when using live_track=1 and render_once=0!)
generate_mipmaps=0 ; 1 Turned it off and that fixed the Qlog errors. Hoorah!
Thanks DavidI, I'll try that

 

[Ruud]

Ruud, it would be far, far better to have shadows and let us decide which shdows to turn off! I have 135 cars and 140 tracks that would require editing the .shd file in each. A real PITB! How about putting shadows back on?

Anyone looked at TrackEd in this version? Models were all yellow when I looked at Early Fall in Norway but the sky was ok. The dky was bad when running it in Racer, See my previous post above.

I don't agree with the shadow default you're proposing. It's easy enough to put 'cast_shadow=1' in all the shader templates, and it will work again. The thing is that this is the quick route, but leads to much less than optimal framerates. I gained ~30% on our Zandvoort by just handpicking a few noticable shadow casters, and forgetting about the rest (road, grass, far-away objects, all making up for lots of fill bandwidth). So I think this is the 'right thing'; doing it the other way around means that modelers who are concerned with framerate have to put cast_shadow=0 explicitly everywhere, then start turning shadows on. That isn't stimulating the modelers to develop high-framerate tracks/cars, but just the other way round.

On TrackEd, in F4 (object property) mode, the models are now colorized to quickly identify objects that need modifications. From racer.nl/tracked.htm: "F4: select model properties mode. This colorizes the objects, depending on the flags set for a model. Red=collidable, green=surface, yellow=collidable+surface (v0.8.37+)."

 

[Ruud]

Boomer Early Fall CG version (at least the one I have here) is using its own custom sky shader in the tracks /cg folder

vf_sky
{
  vertex_shader
  {
    file=cg/sky_daynight_v.cg
    ;file=sky_v.cg
  }
  fragment_shader
  {
    file=cg/sky_daynight_f.cg
    ;file=sky_f.cg
  }
}

If i remove the /cg & use the default Racer shaders, the sky works as expected. The tracks sky shaders are incompatible with racer now it would seem.

And I should point out that the future will be GLSL. I'm working on that already; I should make a small list of things I want to do before v0.9, GLSL is hopefully one of them. Do note that it maps almost 1:1 to Cg, so the only real plan I have is to drop the .cg prefix, but probably accept it anyway (and replace with .glsl) silently. On the other hand, you can consider there being almost no approved v0.9 content, and we can build this up from scratch, where you need to go through .shd files anyway (and this is a simple Search&Replace).

 

[Some1]

And I should point out that the future will be GLSL. I'm working on that already; I should make a small list of things I want to do before v0.9, GLSL is hopefully one of them. Do note that it maps almost 1:1 to Cg, so the only real plan I have is to drop the .cg prefix, but probably accept it anyway (and replace with .glsl) silently. On the other hand, you can consider there being almost no approved v0.9 content, and we can build this up from scratch, where you need to go through .shd files anyway (and this is a simple Search&Replace).

Ruud, once more I propose "globally defined shaders" approach:

Instead of having "vf_*" type supernodes in every single .shd file, why not define them somewhere in "data/renderer".
We could have a number of more commonly used shader types, like "standard", "sky", "window" etc.

With the ability to override all properties, a content creator could write a car shader like this:

shader_body~vf_carbody
{
  layer0
  {
    map=carbody.tga
  }
}
shader_windows~vf_carwindows
{
  layer0
  {
    map=carwindows.tga
  }
}

Here, the "vf_carbody" and "vf_carwindows" could be defined in "data/renderer/materials.ini" for example, and would look something like this:

vf_carbody
{
  vertex_shader
  {
     file=...
  }
  fragment_shader
  {
     file=...
  }
  fresnel
  {
   ...
  }
  cast_shadow=1
  ...
  [more attributes]
}

I think, this approach would help to keep content more unified and guide modders to do things the same way.
Also, It would help to keep the content less dependent on changes in Racer graphics engine.

What do you guys think?

 

[Mr Whippy]

I don't agree with the shadow default you're proposing. It's easy enough to put 'cast_shadow=1' in all the shader templates, and it will work again. The thing is that this is the quick route, but leads to much less than optimal framerates. I gained ~30% on our Zandvoort by just handpicking a few noticable shadow casters, and forgetting about the rest (road, grass, far-away objects, all making up for lots of fill bandwidth). So I think this is the 'right thing'; doing it the other way around means that modelers who are concerned with framerate have to put cast_shadow=0 explicitly everywhere, then start turning shadows on. That isn't stimulating the modelers to develop high-framerate tracks/cars, but just the other way round.

On TrackEd, in F4 (object property) mode, the models are now colorized to quickly identify objects that need modifications. From racer.nl/tracked.htm: "F4: select model properties mode. This colorizes the objects, depending on the flags set for a model. Red=collidable, green=surface, yellow=collidable+surface (v0.8.37+)."

It's a double edged sword.

Most of my content had cast_shadows = 0 where I decided things didn't need shadows casting. So I went through by hand and picked those that didn't need it.

The workload this time is the same, you pick the ones you DO want to cast shadows.


The ultimate result is that shadows off is annoying and looks bad, so you WILL spend time adding the flag in to bring them back. The downside just like before though, is that an author in a hurry will just add cast_shadows=1 to everything again.

Anyone who didn't do it properly before because of ignorance or time constraints, will just ignorantly flag everything on again instead.


I'm not sure which is best. It doesn't really matter in the end. To make good content takes work and time. If you want to cut corners or ignore certain optimisations, you always will be able to!

Dave

 

[Cosmo°]

On another note I had very strange MOI problems with the last version, the roll/pitch/yaw seemed to be coupled in a very odd way, it tried adding a huge number to each parameter, one at a time to isolate the problem. It appeared at first that the roll and pitch were reversed, but then it would act normally. Sometimes the roll moment seemed to be VERY high and the car would roll back and forth at low speeds but when I contacted the track it would suddenly go VERY low. It's fine now though.

I saw your earlier post in this thread which I think was hinting at the same thing, but it would be nice if you could tell us a bit more about the how's and when's. I know Ruud is looking at the CoG definition again, but last I know he hasn't made any decisions or changes yet so I'd rule out anything from that direction, though it would be pretty important to get on top of potential issues related to such core features.



I would also like to see either the window shader going back to where we were before the recent change, or going with something like Stereo proposed, which allows us the freedom to set opacity, reflectiveness and diffuse info independently.



On the default state for cast_shadow, I can obviously see why this was done as quick "fix", but as Dave said it means that those couple of people who actually paid attention to efficient packaging/shading etc have the same workload in front of them now (again, since we already used cast_shadow=0).
Well, maybe a bit more even since we're working mostly on vehicle content, compared to the number of tracks. All vehicles will want full shadows for everything versus turning off a couple of terrain bits, distant trees or buildings on a track.

Yes, it can be a big framerate boost to have it off by default, but optimized content will be the same before and after (and lazy authoring will, as others have mentioned result in no shadows or all shadows anyway). It's hardly an argument to say 50% framerate boost, when in turn you get a bland view. What's next, Racer deciding to run at half the desired resolution because it gives another 10%? I'm just joking here, but this would be a similar logic in my opinion.

The thing is that by now we are all pretty certain that things like huge amounts of individual material shaders have a big influence on performance in Racer. This also means that inefficient releases are exactly the ones that are least likely to be properly adjusted with handpicked shadow casting - simply because nobody likes to sit there and go through 200 identical shader entries for single road signs for example. The motivation is rather low from my own experience.

Ruud has updated Swiss Stroll to Cg some time ago, so he knows this - it's a good example of really nice looking track, which is a nightmare to work on or update, simply because of the structuring and how it seems to have been built with only the initial creation in mind. Getting people to try and set things up cleverly is what we need to do with good examples in the community and through how the documentation words things and recommends methods - giving them a free master switch for a framerate boost isn't going to change a lot of people's approaches to the topic.

Anyway, in light of wanting to get a final out and yet another step in the graphics engine ahead of us, I don't really see why we had to change it all over now to be honest - lot's of small amounts of work is still tedious

It's been done now, we have adapted our shaders to the situation and the last thing I want is another u-turn now... so, just a bit of a rant on these kinds of changes that might have felt like a good idea at first, but a little practical testing would've shown where they really stand

 

[Alexander Knoll]

Anyone looked at TrackEd in this version? Models were all yellow when I looked at Early Fall in Norway but the sky was ok. The dky was bad when running it in Racer, See my previous post above.

Hi Bob,
look in to the release tread from v 0.8.37...

- TrackEd now colorizes the Collide and Surface flags in Props mode (F4) for easy tweaking of flags.

...

 

[Stereo]

On the default state for cast_shadow, I can obviously see why this was done as quick "fix", but as Dave said it means that those couple of people who actually paid attention to efficient packaging/shading etc have the same workload in front of them now (again, since we already used cast_shadow=0).
Well, maybe a bit more even since we're working mostly on vehicle content, compared to the number of tracks. All vehicles will want full shadows for everything versus turning off a couple of terrain bits, distant trees or buildings on a track.

There are a few vehicle materials that don't demand shadows (on the RX7 - decals, gauges, brake calipers to name a few - windows too, if the frames weren't in the same material), and like you said they have much fewer shaders total. It probably won't be as big an improvement as removing cast shadows from the ground of a track, but it all helps.

If a track does have cast_shadow=0 on appropriate materials, you can just fill in cast_shadow=1 in the vf_* templates and reverse it. Tracks do somewhat need a better ini editor though, that handles bulk materials/objects in groups.

 

[QuadCoreMax]

@Some1

I was also thinking of a more structured way for building content, as most of it, is reused thru other files like shaders, generics objects dofs (seats, wings, wheels..) & other stuff like generic textures (carbon, alcantara..), scripts...

==========================

Other changes (no TrackIR tutorial yet) :

- Look_up/look_down controls added for to make TrackIR devices possible. See http://www.racer.nl/XXXXX
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)

About FreeTrack or even FaceTrackNoIR which both are doing a great job at simulating head movements solely on 1 webcam for the latter, what do I need to set in Racer to get the car camera move along with my head movements ?

http://facetracknoir.sourceforge.net/home/default.htm
http://sourceforge.net/projects/facetracknoir/

I'm so excited to make it work with Racer !

FaceTrackNoir devs seems to be updating & working 'hard' to make it compatible with other games, for sure, those kind of ideas, instead of wasting or believing that you would need a device as IR Track, is the cool actual reality of our lifes.

We all somehow re-invent the world & use all kind of different ways/ideas to achieve our goals quicker. Sure, big corporations needs really to take into account those variables & never under-estimate our intelligence, our wishes to do better but with less matter. I mean, you just need 1 webcam with FTN program...

Make sure, you wait some seconds when the algorithm detects your face...Eventually, uncheck the exposure parameter on & then off + resave/reapply, your FPS should then increase to stable framerates.

Let's merge with them & see if we can build something together which isn't found in other racing games !

 

[QuadCoreMax]

I use reload shaders lots too, and it works flawlessly. I had issues when it first was added, but in the last year it's been a bulletproof feature..

So, you saying you reload shaders & keep driving ingame without any need of exiting & reloading the whole ?

I just tested it on my ATI machine, on this version, nope doesn't work as I'd imagine, any ATI GPU user having the same issue ?

Strangely, it's a persistent bug I grew up with from the 1st time I joined you with the 0.8.10...
I also tried to reload track command after the shaders command but it isn't helping.

 

[Mr Whippy]

So, you saying you reload shaders & keep driving ingame without any need of exiting & reloading the whole ?

I just tested it on my ATI machine, on this version, nope doesn't work as I'd imagine, any ATI GPU user having the same issue ?

Strangely, it's a persistent bug I grew up with from the 1st time I joined you with the 0.8.10...
I also tried to reload track command after the shaders command but it isn't helping.

I can run reload shaders command every 5s for ages and ages.

I tweak all my shaders like that.

I can see how it is annoying if it doesn't work for you though!

Not sure on the fix then... do you explicitly set you have an ATI card in racer.ini?


My 2p is buy nVidia next time. ATI are pants hehe

Dave

 

[Stereo]

reload shaders works for me, reload track on the other hand is not working, though I haven't looked carefully for when it breaks. Something with collisions I think. I do have nVidia.

 

[Alex Forbin]

reload shaders works for me, reload track on the other hand is not working, though I haven't looked carefully for when it breaks. Something with collisions I think. I do have nVidia.

Reload shaders doesn't work here and I'm running Nvidia cards, it makes parts of the car disappear.

I saw your earlier post in this thread which I think was hinting at the same thing, but it would be nice if you could tell us a bit more about the how's and when's. I know Ruud is looking at the CoG definition again, but last I know he hasn't made any decisions or changes yet so I'd rule out anything from that direction, though it would be pretty important to get on top of potential issues related to such core features.

I'm really not certain what was going on, rotation on axis would behave as normal but anytime there was a diagonal movement in a couple of axis at once it would behave as though one axis had a very low MOI. I think it might be a good idea to scrap that section of code and just start over since it's so important to handling.
The only reason I can see for bugs constantly showing back up is due to recycling routines, while this is not an unusual practice, after 10 years of development it would probably be a good idea to rewrite some of the more important routines from scratch since I'm sure that Ruud (like the rest of us) has learned a few tricks in that time.

Alex Forbin

 

[QuadCoreMax]

@Stereo + Dave

Sorry, but I still don't know, if you are able to continue playing/driving once the command is executed ?

I'd like to take this commands into my scripts & be able to continue without no issues..
=========================
The wireframe command is back on ATI

 

[camsinny]

Reload shaders stuffs up on some tracks for me, IIRC it doesn't work on Swiss Stroll, forest club and a bunch of others. Works fine on carlswood and roggel though.

Also, just noticed the blog on racer.nl has been updated. Finally! haha

I see you have good FPS Ruud, I assume that's because everything's in the early stages and there's no shadowmapping and everything...can we expect comparable framerates when GLSL fully implemented or do you expect a slight or large increase in the FPS we get?

 

[boomer541]

I reread the Readme file (v0.0838) and noted the "Good graphics card reguired" or turn off "generate mipmaps." That was the source of one of my problems.
I have an nVidia GTX285 graphics card running ver 6.14.11.8206 driver. So why didn't it work? Do I possibly have some obscure setting wrong? What is now considered a "Good" graphics card? My GTX285 is only 2 years old, purchased 1-2010.
The sky was ok in ver 0.0837 so something chabged and I haven't figured out just what yet.

When I did the Sugo update I did the shadows selectivly by putting in a shadow and then checking the effect for each of over 100 textures.
Killed the battery in my mouse twice. LOL