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.

 

[skybh]

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

Hi,

For me i could not make shaders counts low, i think textures count low could be ok..

Why i can't ? Let's take an exemple :

I do a car with several colors variants.
So in the variant 1 have :
-White body, dark top of dashbord, light buttom of dashbord
-Red body, light top of dashbord, light buttom of dashbord
-Blue body, light top of dashbord, dark buttom of dashbord
etc, so what would be better, 1 texture per variant (wich will make an huge archive), or just an white with shader tweaks for colors?
Another exemple : it the petrol and diesel engine had different rev counters, we'll have a shader for kmh gauge, another for rpm gauge, or having two big textures..

I prefer have a lot of shaders than a lot of textures . Also it's easier to change variant with this

 

[DavidI]

Hi,

For me i could not make shaders counts low, i think textures count low could be ok..

Why i can't ? Let's take an exemple :

I do a car with several colors variants.
So in the variant 1 have :
-White body, dark top of dashbord, light buttom of dashbord
-Red body, light top of dashbord, light buttom of dashbord
-Blue body, light top of dashbord, dark buttom of dashbord
etc, so what would be better, 1 texture per variant (wich will make an huge archive), or just an white with shader tweaks for colors?
Another exemple : it the petrol and diesel engine had different rev counters, we'll have a shader for kmh gauge, another for rpm gauge, or having two big textures..

I prefer have a lot of shaders than a lot of textures . Also it's easier to change variant with this

You have missed the point, it is the amount of shaders loaded for one model variant, don't use 100 shaders for one car if you can use 10. Same goes really for individual textures, as it always has. minimal everything is better for fps. A balance of both is the key.

 

[Mr Whippy]

Yeah, it's not so simple really.

I think a white car is good then use shaders to colourise it. That is what I did on the Lambo.

In theory you need three shaders if you have two interior colours and one exterior colour. I don't think that is so bad.

The issue does come, as David says, when you have about 20 shaders that are all basically identical, and all use little textures that could all be in one texture/shader.

Every call for a texture or a shader is costly basically, one of the most costly things for FPS. If you can draw something using the same shading technique as another thing, and make them both share a texture, you have just saved a call for a shader and a call for a texture.

In my view, a car should be doable with about 10-15 shaders/textures. Remember, when you are in the high quality interior, you can turn the exterior of the car off, so the wheels and their shaders go, as can other exterior details. So for your interior you can get quite a lot of shaders too if you are clever.

Also, it seems, that a shader pass is made per item that owns that shader. So if for example you have a car with 20 panels, and each one has "panel" shader, then each panel is called separately if they are separate geometric items within the whole DOF.
So merging/attaching objects together with the same shader is also good practice, even if they are in the same DOF. However, there is a limit to the vert count, about 20,000 iirc. So if you have too many verts per object within a dof you get missing verts as Racer won't draw them.

Basically, optimisation is important. A combo of scraps of textures, shaders that all look to do the same thing, but reference those scraps, and geometry that isn't optimised for those shaders, results in really slow FPS.

It's quite stunning how well a nice looking but un-optimised car can just totally suck the FPS from your scene.

I recently developed a car with average texture/shader and polygon count, and simply merging the meshes at final export to DOF got me 65 > 85fps!

Eeek!

Dave

 

[skybh]

The issue does come, as David says, when you have about 20 shaders that are all basically identical, and all use little textures that could all be in one texture/shader.

For this i just use a white texture, then add color with ambient/diffuse parameters

In my view, a car should be doable with about 10-15 shaders/textures. Remember, when you are in the high quality interior, you can turn the exterior of the car off, so the wheels and their shaders go, as can other exterior details. So for your interior you can get quite a lot of shaders too if you are clever.

In the renault 21 they're 22, maybe i'll add some other (lights). About the textures, i use something like 14.. (two 1024*1024 and other small). They are some cases that i can't avoid, some part have a mapping that is repated n times, that's why i use shader/texture for it (mostly plastic/seats)..

Also, it seems, that a shader pass is made per item that owns that shader. So if for example you have a car with 20 panels, and each one has "panel" shader, then each panel is called separately if they are separate geometric items within the whole DOF.
So merging/attaching objects together with the same shader is also good practice, even if they are in the same DOF. However, there is a limit to the vert count, about 20,000 iirc. So if you have too many verts per object within a dof you get missing verts as Racer won't draw them.

Could be an idea, but there is a problem too, the problem is trim levels..
Let's take an exemple, in the espace III that i've relased, we can chose between 2 chassis and 3 trim level, right?
So if i've :
trim 1 : black bumper, no roof racks
trim 2 : black bumpers, roof racks
trim 3 : colored bumper, roof racks.
so i the body is all, i'll have 1 body per trim level = bigger file size..
I prefer "split" the body in seperate object, easier to do variants, with this i do a main body where i put part that can changes (roofs racks, sun roof etc..)
But, how about scripted objects?

You have missed the point, it is the amount of shaders loaded for one model variant, don't use 100 shaders for one car if you can use 10. Same goes really for individual textures, as it always has. minimal everything is better for fps. A balance of both is the key.

Yeah i know, i try to optimise that don't worry

 

[Cosmo°]

It's a good thing to talk about this, even if this is not the right thread for it per se - so much content is not optimized at all and having people like you come up with questions means somebody cares and that can only lead to more knowledge for everyone in the end

Without trying to sound stereotypically against conversions, they very often offer a good sample of how not to structure content in Racer. Any of the more recent conversions from NfS or FM titles usually have something like 50 to 100 texture files and shaders in the region of 10 to 20kb in filesize - both of which are massively bloated and unnecessarily complicating creation and maintenance of said files.
This also costs a lot of framerate perfomance without any benefit in return. The vehicles don't look nicer than a more efficient example, because most of the shaders are duplicates and generic textures are shared between cars in those games. This part doesn't apply to your scratchmade content of course, but since others are going to read it...



Using generic models for easy variation and selection of trim levels and optional equipment is a great thing and it doesn't stand it in the way of efficient material and texture count either, if that's what you're thinking.

Let's take a well known example, wheel models. We usually have four wheels on our vehicles and if the front and rear axles have different sizes, then that means four individual .dof files in total. The normal thing to do would be to assign one and the same material for all four rim or tyre materials if they're indeed identical. You'd also use the same texture reference in that case. This means that we have one shader call, one texture to load (or two if you think of bumpmapping the tyres), but four models are rendered correctly.

Now whether it's a wheel model or a plastic roof rail doesn't matter - you can have a modular vehicle mesh layout and still easily assign a low number of materials and textures if you plan with this in mind. The paint on a sports model bumper or the one on the regular version are still both paint - so there's no need to assign two different materials for example.

Mesh files used in animation scripts can be treated the same way, too. A door that opens doesn't require a different set of materials than a permanently closed one that's united with the body mesh.

 

[QuadCoreMax]

Without trying to sound stereotypically against conversions, they very often offer a good sample of how not to structure content in Racer. Any of the more recent conversions from NfS or FM titles usually have something like 50 to 100 texture files and shaders in the region of 10 to 20kb in filesize - both of which are massively bloated and unnecessarily complicating creation and maintenance of said files...

Hm, not really, FM3 uses 3 base textures & Shift about 10 or so...It's a matter of knowing how to filter them quickly & reuse/mod the textures like the alpha layer i.e. in Shift, used for the specular shader.

I admit, I'm massively reusing my generics textures (carbon, alcantara etc...) & that works nicely for now. Doing so, you boost time development a lot, because you can use the same shader names everywhere, so the car.shd is quickly compiled.

=====================================
I want Python in our console with Racer objects inside a module mixable with Python custom modules !!!
Imagine a powerful world where there's no more constraints....

I'm actually doing huge progress with Python & my ideas of getting something complete & highly intelligent is on its way (PyRacer Editor)...A Racer custom parser (using pyparsing + configobj modules in 2.7) is build & almost ready, thanks to ALL Python Experts out there !

 

[boomer541]

Perhaps, QCM, we could get an exporter for Blender animations if we had some Python programmers involved with racer.

Blender uses a lot of Pyton scripts.

 

[Mr Whippy]

Hm, not really, FM3 uses 3 base textures & Shift about 10 or so...It's a matter of knowing how to filter them quickly & reuse/mod the textures like the alpha layer i.e. in Shift, used for the specular shader.

I admit, I'm massively reusing my generics textures (carbon, alcantara etc...) & that works nicely for now. Doing so, you boost time development a lot, because you can use the same shader names everywhere, so the car.shd is quickly compiled.

The conversions we actually see though, are really bloated, slow and un-optimised, and just generally horrible from a 'technical' point of view.

If someone releases good F3/4 conversions I don't mind, but they look nothing like as good or run as fast as they do in F3/4

Dave

 

[QuadCoreMax]

@Boomer

Python is everywhere really...& strange coincidence is, it's made by another Dutch programmer (Guido van Rossum)....
Great people around the world should now merge their energy/force into bigger & more 'intelligent' design, that's what I'm trying to do with PyRacer Editor.

The more I learn & experience/discover, especially in Python/Unix World, the more I see multiple ways of materializing ideas, it's now a matter of integrating what was already smartly scripted, into more complex scripts to help us, in getting something which will litterally suppress the need of doing the stuff manually. (car.ini, car.shd etc..)

@Dave

Sure, but let's wait for a little while...
I still believe we're at the frontier of a new age, I bet he's already looking at Quantum Programming & stuff, lots of people in the same position are researching & building new systems to solve complex problems/ideas.

Anyways, like Cosmo explained, the wheels example is a perfect one, why would it be necessary to plug 4 different wheels, when we all know they all coming from the same 3D object ? They could be scaled/positionned via a matrix file as found in Shift (vhf file)...
Also, having wheels=4 in car.ini is implicit, so another waste, to theoretically avoid in future updates...

 

[camsinny]

@Boomer
Sure, but let's wait for a little while...
I still believe we're at the frontier of a new age, I bet he's already looking at Quantum Programming & stuff, lots of people in the same position are researching & building new systems to solve complex problems/ideas.

Anyways, like Cosmo explained, the wheels example is a perfect one, why would it be necessary to plug 4 different wheels, when we all know they all coming from the same 3D object ? They could be scaled/positionned via a matrix file as found in Shift (vhf file)...
Also, having wheels=4 in car.ini is implicit, so another waste, to theoretically avoid in future updates...

You can wait as long as you like but they're still going to be unoptimised. At least for racer's engine.
(If you're referring to Ruud) I can almost guarantee he's not looking into quantum programming.

And about the wheels=4 why should it default to 4?

Pretty sure that Kamaz has 6 wheels.

 

[boomer541]

My GTX285 failed and I replaced it with a GTX560 Ti which all indications stated that it was equal or better than the GTX285.

It appears to give a bit higher fps but I'm not sure I have it set up for optimum performance for RACER.

Looking forward to the next update which is a bit overdue.

 

[DavidI]

My 460GT can run 3840*1024 across three monitors @ 30-60fps depending on the track/cars. A 560TI should do a touch better. With the same settings running from your 285 it should be same or better performance. Make sure you are using the latest beta drivers off nVidia website, and also have a play around with the settings in the nvidia control panel, you'll have to add Racer.exe as an app & then customize the settings with it. I've been using antialiasing- transparency = multisample, makes things like chain-wire fences and other transparent objects look a heap better.

 

[Alex Forbin]

My GTX285 failed and I replaced it with a GTX560 Ti which all indications stated that it was equal or better than the GTX285.

It appears to give a bit higher fps but I'm not sure I have it set up for optimum performance for RACER.

Looking forward to the next update which is a bit overdue.

I have one of the 560Tis in one of my systems and it seems to do well, make sure you have it set to "single display mode" for best performance.

It does seem like we're getting fewer and fewer updates these days, bi-annual? Oh No!!

Alex Forbin

 

[boomer541]

Thanks for the hints, gentlemen!

Menu Problem
After selecting options/graphics making NO changes click "accept" and return to menu and click back, then select quick race and select car/track. car won't move or start or anything else, can only esc (exit) and get the following Qlog error:

[racer/568] racer.ini:renderer.shadowmapping.enable is not 0 but shadow.project_shadows=1
[racer/568] That would give double shadows; ignoring shadow.project_shadows (set it to 0)

Racer.ini file shadow.project_shadow is set to 1. Shadow mapping was and is enabled!

This is not good when nothing is changed there should be NO changes to the racer.ini file!!

 

[Alex Forbin]

Thanks for the hints, gentlemen!

Menu Problem
After selecting options/graphics making NO changes click "accept" and return to menu and click back, then select quick race and select car/track. car won't move or start or anything else, can only esc (exit) and get the following Qlog error:

[racer/568] racer.ini:renderer.shadowmapping.enable is not 0 but shadow.project_shadows=1
[racer/568] That would give double shadows; ignoring shadow.project_shadows (set it to 0)

Racer.ini file shadow.project_shadow is set to 1. Shadow mapping was and is enabled!

This is not good when nothing is changed there should be NO changes to the racer.ini file!!

Confirmed here as well, this is really a weird bug.

Alex Forbin

 

[Mr Whippy]

The Racer menu system is a bit iffy.

I prefer to do everything via Notepad++

It's just the nature of so many changes all the time. I guess it's these kinda things that could be resolved at a v0.9 final... release v0.9, then spend time after that point only resolving bugs present until we are all generally happy that it's a stable sensible platform to work from.

A friend who is very much into real cars/tuning/suspension tinkering (custom suspension pick-ups and kinematics for his TVR) has recently got into Racer... but is tripping up constantly over bugs like that one above. You just expect a menu to work if it's there at all.

No bad thing really, we know Racer is good underneath. I do wonder how many 'new' people are put off by simple bugs these days though

Dave

 

[Ian Strom]

In the case of Racer bugs and incompatibilities have always deterred new people I have talked about Racer with. It is nothing recent.

 

[LostAngel]

I am very new to it but i can see the quality and the work and time put into this program to make it what it is, i have enjoyed it for about a week now and have loved it and all its bugs. Hell, i am still trying to fix a simple problem but while doing so still having fun as well.

 

[DavidI]

For anyone using an NVidia 8 series or newer GPU, try the newest 300 series beta drivers (version 301.24 currently for Win7x64). There's a new FXAA option, which seems to do as the release notes say, same as 4x MSAA, but with far lower GPU hit. I'm getting quite good visual quality, but have frame rates not dipping below 100fps, whereas before I'd get anything from 70fps to 130 with same car on same track depending on where I was on the track.

 

[boomer541]

I'm using, I think, 295 from nVidia for Win xp and got over 360 fps on a track, Wow!