Wanted - community feedback

[Cosmo°]

Cruden are currently at the Automotive Testing Expo in Stuttgart, with one of their motion platforms, but more importantly, very friendly staff. I took the opportunity to visit them today and had a highly informative chat with Edwin de Vries, who's their senior modeling and simulation engineer. We talked physics, bugs, projects and ideas for the future. Edwin kindly offered to keep the discussion going, and - if work permits - that might lead to him and Ruud looking into some of the most urgent points that we raise in the community. I figured it would be helpful if we were to collect everybody's ideas in a single thread, so that it's easier to manage and then pass it on.

Post here what you think are the most urgent bugs that need fixing, which existing features you want to see developed further and also what kind of new features would bring Racer forward. If one of your points has already been mentioned, you want to quote or refer to it otherwise, so that we can get a sense of the popularity. Also, please spread the word among fellow Racer communities to participate as well.

 

[Mr Whippy]

So I guess the shader that is causing visual issues from the wheel also uses transparency?
Ie, if you disable transparency for that shader the wheel is using, does the problem go away?

Just trying to isolate the shader/s that are not blurring properly, since it seems to be the same shader that is going wrong on my interior gauges by the look of the visual issue characteristics.

Cheers

Dave

 

[Alex Forbin]

Good idea Dave, unfortunately I get the same results with blend on the wheels turned off.

Alex Forbin

 

[Mr Whippy]

Is that light green stuff transparency mapped?

The tops of the wheels look ok, but the parts being overlapped by a much different velocity (the static grass in front of them) is making problems happen.

I've not had chance to look at this yet, I've been busy playing with other shaders though.



I'm not sure how/why it works, and I'm not sure if it was possible formally or not, but having shadows cast using the gequal transparency, but using the smooth blendfunc=blend for actual transparency.
So you get the nice blending but with shadow casting too.

I've also been playing more with mip alpha setting for things.

Mainly making wire fences look a bit more real and light up realistically, and do all the things we want nicely, rather than averagely with a bog standard transparency only shader.


Another little job on my list is to fix the damn dials in my Z4 interior, they drag loads like the above motion blur issue you have Alex. It's got to be related to some transparency stuff.

Now to go see if I can output the velocity map to the fs_filter and try figure out if it's a weird issue there, or if it's actually some other shader not using it properly!?

Hmmm

Dave

 

[Alex Forbin]

Is that light green stuff transparency mapped?

The tops of the wheels look ok, but the parts being overlapped by a much different velocity (the static grass in front of them) is making problems happen.

I've not had chance to look at this yet, I've been busy playing with other shaders though.



I'm not sure how/why it works, and I'm not sure if it was possible formally or not, but having shadows cast using the gequal transparency, but using the smooth blendfunc=blend for actual transparency.
So you get the nice blending but with shadow casting too.

I've also been playing more with mip alpha setting for things.

Mainly making wire fences look a bit more real and light up realistically, and do all the things we want nicely, rather than averagely with a bog standard transparency only shader.


Another little job on my list is to fix the damn dials in my Z4 interior, they drag loads like the above motion blur issue you have Alex. It's got to be related to some transparency stuff.

Now to go see if I can output the velocity map to the fs_filter and try figure out if it's a weird issue there, or if it's actually some other shader not using it properly!?

Hmmm

Dave

Yes the foreground is transp. mapped using gequal 128. Am I reading you right in that I should use alphamapping AND blend as well? I was under the impression that alphamapping was to be used whenever possible instead of blend for speed reasons.

Alex Forbin

 

[Mr Whippy]

Hey Alex,

Yeah I'm a little confused to all the nomenclature for shaders/transparency and what is needed etc.

I was recently trying to throw a trans map in with the normal map, as it's read linearly which is probably better for alpha blending in mips with DDS and alpha to coverage.

So I was struggling with shadows not being cast if that was the case. Shadows seem somehow hard coded to layer0 alpha.
Probably not but I was just digging and messing around.

Any way I think alpha to coverage just deals with alpha for transparency and as a boolean for fast transparency calculations. Ie, hundreds of transparent layers just get a pass/no pass and that is that which is much faster than blending with 255 levels each time!

This is also required for CSM shadowing because they just need a pass/no pass, they can't pass through semi-transparent stuff.

BUT, for say a wire fence that is really near the track then the cost for that to be blended with a full alpha channel seems worthwhile, especially as it mips down and wires can disappear easily etc.

So any way, I just added blendfunc=blend in the second layer, trying to pick up alpha off the normal map, and suddenly I get alpha to coverage for shadows, but the actual visual blending is done with blend.
And it's using the layer0 alpha still. Weird. But hey, it works. You can then use alphafunc gequal value to adjust the way the shadows are cast, but the blending is always nice because it's using blendfunc blend.


So right now I'm tweaking a nice trackside wire texture with appropriate mips and values so it looks just great and fades into the distance really nicely.


I think Stereo might be able to explain the inner workings of this stuff more than I can.



But for now I'm just guessing that alpha isn't being dealt with entirely properly with the velocity map generation?

Perhaps like CSM, the velocity map can't see through blended items, or some tweaks need to be made to some shaders to allow it?

Or something like that?

Ie, if that grass is removed in the image, does the stretching/weird lines go away in the same place?


Remember that Racer shaders are many years old now, but some are new/updated.

There is a chance that the odd shader just does stuff a different way wrt transparency and that breaks certain effects.

A quick check of the velocity map output will probably reveal the issue.

Remember you need to drive a few seconds before it begins to get updated...



Cheers

Dave

 

[Stereo]

So I was struggling with shadows not being cast if that was the case. Shadows seem somehow hard coded to layer0 alpha.
Probably not but I was just digging and messing around.

That's quite possible, I don't know if rendering the shadowmap is done with the usual material shaders, since the result is a depthmap and the only texture info it needs is alpha blend style.


The pass/fail alpha coverage is a way to deal with render order of transparent objects as far as I know - you can render them in any order since they write to the depthmap like solid objects, so it's good for x-trees etc. where you have a bunch of transparent objects visible through each other in not really predictable order. It might also be faster.

 

[Mr Whippy]

Yeah, I think it's when lots of transparencies stack it gets really costly.

But say you have a wire fence and then a forest behind it, you can certainly do the nicer blend on the wire fence, and then do everything beyond it the fast way.

With good mip-maps on things like trees you can generally get a perfectly ok look with the alpha testing transparency types.


PS Stereo, a bit OT for this thread, but have you read about metalness maps in PBR shaders?
They generally just use an 8bit channel as a boolean for using a pre-fixed fresnel variable (could set in the shader or in the actual shader entry in .shd file) for everything, but if metalness is flagged then it uses the base map albedo, since metals have zero albedo any way.

Obviously it's not perfect for things like oxidised metals etc, but as an optimisation it seemed quite nice for a lighter weight PBR shader that did both types of materials.
It seems quite popular in the game world and stuff there tends to look ok.

It also seems they like to use rgb DXT5 textures, but not use alpha as it's quite inefficient on memory size.
Better to use more rgb maps.

So I was just thinking maybe it'd be cool to re-visit the PBR stuff. These changes seem pretty easy really.

Also I noted they use a cavity map (like a higher contrast AO map) for specular occlusion (multiply)... I'm not sure if it's used elsewhere, but it's like we have AO for diffuse and then Cavity for spec

rgb albedo/diffuse
rgb normals
rgb ao, cavity, metalness


That at least would lend itself really well to fully uv unwrapped cars and interiors etc, where you have chrome, plastics, leathers etc... and shading really adds the depth to all the details (ao and cavity to help)

I recently did some F1 tyres for that F1 car update with the PBR shader and they look really good on a properly set up track (no pesky sun spot in the envmap!)

Dave

 

[Mr Whippy]

An example of a nice fence shader/texture with nice shadows and also blending.

FPS impact seems kinda irrelevant. I see no change using a 1024 diff + alpha and 1024 normals, to just using a simple diffuse + alpha map at 512px.
Maybe you won't spot these details, but hey, while you're throwing textures around you may as well paint a nicer picture if you can, for pretty much free GPU cost it seems.

As with most things in Racer, the real issue is just getting everything into a full car/track combo and it'll all look great. That said look at the hour counts going into tracks like COTA for iRacing and some of the Forza 5 tracks. 1500 hrs+ Eeek!

OK a few areas of Racer are annoying, more than I can list on one forum page haha... but generally you can get a great looking track, and a great looking/handling car, and have fun in the right conditions.


It all just falls apart with these small details which are what we need to get right I think.

Things like multi-player erratic behaviour with scripts makes enjoying decent content nearly impossible. Turning off scripts that help road cars feel half decent then ruins the experience (ie, back to the limited ABS defaults, or no power steering emulation, or awd emulation etc)
A system to allow the same car in many configs in multiplayer would be useful so we can just have one car downloaded and all drive different colours/specs (think like the Murcielago nested gearbox options somehow being passed between peers, it's all the same car.ini or car.shd, just different bits are referenced per peer car)

Have a lobby hosting system somehow? Double check car and track folder names/ids?

Or have ability to have the host have links to content that they are hosted somehow?!



OK they may not seem essential for Racer's primary purpose, but as a Free Racer they are just stopping Racer at the last hurdle from becoming something really usable and enjoyable as a free platform to enjoy car driving and racing.


I honestly think Racer today can look and feel as good as the best sims/games out there in this genre, in the right situations.
There is no reason why we couldn't have tons of WIP tracks and cars again, like we did in the early 00's with an original track a week it seemed, and every car you could dream of being released, often from scratch too before any other game.

All that potential is still there, and I think the only missing thing is getting those niggles that stop that content then being enjoyed together fixed!

If anything it's probably even more critical these days with on-line and social stuff being so popular


Dave

 

[Mr Whippy]

Awwww pants, it's not working properly now I've got alpha tested transparency between it and other things...


So it can blend properly using blend, even with alpha tested stuff, but it won't then cast a shadow.

If you use alpha testing it'll pass a shadow, but the alpha gequal approach is not as visibly pleasing.

If you try use both then it breaks the blending.


I'm betting there is a way to set this up so you can do both ok.

Dave

 

[Harey]

Things like multi-player erratic behaviour with scripts makes enjoying decent content nearly impossible. Turning off scripts that help road cars feel half decent then ruins the experience (ie, back to the limited ABS defaults, or no power steering emulation, or awd emulation etc)
A system to allow the same car in many configs in multiplayer would be useful so we can just have one car downloaded and all drive different colours/specs (think like the Murcielago nested gearbox options somehow being passed between peers, it's all the same car.ini or car.shd, just different bits are referenced per peer car)

Have a lobby hosting system somehow? Double check car and track folder names/ids?

Or have ability to have the host have links to content that they are hosted somehow?!

Dave

As far as I know the original multi-player system (connecting to a specific IP) the only thing that had to be the same with the cars was the folder name, and the car's ID.

As for the scripts I think having two types, one that is local, and another that is global, would work well. The local one would still work on the local car on multi-player mode, and be good for ABS, power steering, or awd emulation. While the global scripts would be more useful for moving parts on cars, like folding mirrors, working turn signals, or moving sunroofs.

We have a lobby in Racer, but I've found it to kinda be useless, and revert to just directly connecting to the IP's. Syncing car data would be useful, but you'd have to kind of be careful with it, like the system should ask if you want to share a specific car, or track publicly.

 

[Mr Whippy]

Yeah, it's just managing all that folder names. A good car might be say 30meg at least.

If you want to have a yellow one, a red one, and a blue one, then that is 100meg just so different people can play with a different coloured car. The ID and folder names all need to be correct too.
Duplicating 99% of the data just so one shader variable can be different isn't even a feature, it's a lack of a feature that should be simple to implement.

Yeah, scripts should just default to the car. Parts moving could be argued should be local too by default, so only you see them on your machine/car.
THEN if they need exposing to others so your car changes to them, then allow that. There are lots of times you might just want a local change but it's irrelevant to other players visual models of your car.

Basically, scripts in car folder should have no other influence than on your instance of your car, be it in local play or multiplayer.
So it defaults to always just be a local scope for YOUR car, then if you want it to work differently you script for that need.

99% of the time my car scripts only ever need to run on my car.



I think when I say sync car data I mean that the car.ini and car.shd files are used from the clients joining.

So for example the shader will have all the colours defined for the car body paint material say, and with a nested reference you can just change one line to change the colour.

These reference lines are then exposed in the selector screen for the cars, and that information can be 'linked' to your version of that car when you load into a multi-player game.

Ie, I choose yellow and host a game, you choose red and join. All the car.ini/shd files are the same, but that single line is allowed to be unique per joiner and so their cars appear correctly to each other.

So rather than copying 99.9% of the data so we can have different coloured cars, we just send 0.1% of the data at connection that defines the car colour instead.


It really can't be that tough, rFactor had such features years ago and it still works great today!

Dave

 

[Stereo]

Instead of requiring specific lines I think I'd just do like the track geometry suggestion and have a specific one that gets added onto the main file.

Like car.shd + car_red.shd, where it'll load settings from car.shd first, then replace any that are defined in car_red.shd.

Same for car.ini, addon versions only need to define the specific parts they change... if you want to go full-on upgrades like rFactor, you could have multiple inis selected (car.ini, car_borrani_rims.ini, car_427_engine.ini) that just load/replace in the order you've picked them.

The game afaik already does this sort of multiple replacement loading (to get defaults), just needs logic to let the player choose what inis to check, maybe a list in some new file so that we can have our external configurators handling any logic (eg. only let 1 replacement wheel model be used at a time).


It's been a while since I played with a car.ini, but it seems like you could use the generic model section for visible upgrades pretty easily. Just say model0 is the front bumper, model1 is the front headlights, etc. and be able to override just those specific ones with a second car.ini, as they all load from dofs.

 

[Mr Whippy]

Yeah good idea Stereo.

We also had this with movables001.ini being appended to tracks geometry.ini too.
The long term plan there being movables001...999.ini I guess.

But it all went into one file for some reason which didn't really make life any better but hey ho.


So yeah, just fragments that can be referenced I suppose. I was just thinking how you'd prevent cheating as people could add crazy mods this way. Doing it all inside the base ini/shd would allow you to just check the files crc.
But I do agree the way you suggest is better all round and I'd support it 100% over any other method, but we'd just need a way tfor a server to check all such mod files are the same between peers and no extra files have been added *AND* selected.
Ie, extra files for personal use, fine, but not if you don't want them in multiplayer.



Cheers

Dave

 

[cristianno]

more important: improve traffic and multiple opponent car types

In my opinion, they are not the bugs that chase users, because people understand that it is a software development (which would absolve the bugs Racer)... the problem is, in my opinion, the lack of cultural features games / racing sims, such as traffic and diversity of cars in the same race

another point: with our effort could finish and fix old cars and tracks, because bad content may generate frustation (bad cars, bugged tracks)

sorry for my poor english.. (i am a Racer user since 050, or 2006)

 

[cristianno]

I remembered another point: people who have old computers and are true car enthusiasts still running older versions (0.6.5, 0.8.4 - like me) , because they know the Racer has been - with much advantage - the best ... so I think the rise of simulators like rFactor (before the mods flood the scene) and AC stole many "customers". Good evening everyone. we share the same dream