WIP 2000 Mazda RX-7 Type RZ

[Mr Whippy]

vf_glass
{
fresnel
{
bias=0.15 ; Fresnel = bias + scale*exp(incident angle, power)
scale=1.0; eg. chrome would be more like bias=1, scale=0 as it always reflects
power=2.0 ; power just changes the curve
}

cast_shadow=1
vertex_shader
{
file=dyn_standard_reflect_window_v.cg
}
fragment_shader
{
file=dyn_standard_reflect_window_f.cg
}
}
;----------------------- shaders -----------------------

shader_glasstail~vf_glass
{
sort_offset=1
reflect=0.2
layer0
{
map=lights.tga
blendfunc=blend
depthwrite=1
shininess=13500
ambient=.1 .1 .1
diffuse=1 1 1
specular=3 3 3
}
layer1
{
map=$trackenvmap
}
}

Alex Forbin

Sorry to nit pick, but didn't we decide that glass fresnel values were something more like 0.04 0.96 4.5? Using glass IOR to calculate the proper values? Very close to lacquer on car paint, as they are kinda the same material really. Just glass seems to have a stronger power/falloff amount!?

For any smooth glass surface, reflect needs to be almost 1 to get the mirror appearance at steep viewing angles? (not exactly 1 probably because of tiny roughness or dirt/dust on the surface?)

It'd probably look better and not need the extra specular to look 'right' if the base values for glass were used, and then the opacity channel to tint it can be used to bring the transparency down. Hmmmmm.




It is these settings that perpetually catch me out though.

Ruud hasn't really offered an example of 'best practice' way to use the glass shader or the settings.
Ie, depthwrite is always 1, but we can toggle it off, but then we need to make sure we set a sort_offset to make sure it is rendered appropriately (from what I read on racer.nl)


I suppose this is an opportunity to make a car that has lots of modern 'features' that all work but also using good values, then Ruud can help us make sure it's optimised and using shaders efficiently and logically so we can use it as reference material for best practice!

I've made a few nice cars but have hit issues with glass/blending but got over most of them simply by toggling switches and sort-orders and splitting models so they were done in a different batch... not ideal at all, and not so useful for new content creators who will fight with things for hours!
I guess what I mean is, we could do with hard and fast rules for transparent materials so we can just make them and they just work


Ie, somehow, the Murcielago headlight models use a blendfunc=blend, they appear under glass fine (not the new glass though, hmmm, maybe it's the new glass shader not perfect?), the bloom appears fine under the glass too, and they don't use any special settings bar sort_offset=-1

Yet when I try do the same on some other cars all hell breaks loose haha...
It does frazzle my brain and it's one of those areas that should just work, rather than having you spending hours fudging things and fighting.

Dave

 

[Mr Whippy]

Moved blendfunc=blend on the glass shader from layer0 to layer1 (envmap), and now I at least have consistency - if sort_offset is higher on the glass, then the regular brake lights work and the middle brake light doesn't. If sort_offset is lower on the glass, then the middle brake light works and the outer ones don't. When it's equal, the middle light doesn't work again.

I think the solution is gonna be to split the third brakelight off to its own material, so it can be sorted after the glass, while the other lights are still before.

Removing blendfunc from the brakelights shader just makes the black corners of the polygons visible.

Bloom disappearing under glass would just be due to the 'blend' dimming it, probably.

I just came to this conclusion too, after talking through it in my post to Alex it seemed to be the logical reason for failure in 'brake light' cases... BUT, I think it needs to be a different shader, or a different DOF entirely, to make sure the batch is actually split!

My brake lights all used the same shader in the same DOF, so even despite being different geobs they were probably sent in one pass, and so having lights under glass and others over glass means that there was always gonna be some compromise.

Probably defining the 3rd brakelight as a new DOF in car.ini, and since doing that splits it to another shader, also have a 2nd shader with appropriate values too.

Perhaps that is the way to go.


As per bloom, my Lambo shader works ok in that regard, so again it's probably to do with this sorting/blending issue as per above?! Hmmm...


Finally, not sure if it's helpful but I'll post this again from Ruud:

On the sort order; negative would seem to render earlier in fact:
// Standard sort keys (large gaps to juggle with render ordering)
SORT_PORTAL=100,
SORT_SKY=200,
SORT_OPAQUE=300,
SORT_SHADOW=400, // Often used with polygon offset (before or after SORT_BLENDED_ALPHAFUNC)
SORT_BLENDED_ALPHAFUNC=500, // Blended materials+alphafunc (depthwrite=1 often)
SORT_BLENDED=600, // Blended materials without alphafunc
SORT_ADDITIVE=900,
SORT_RAIN=1000,
SORT_NEAREST=1500 // Last
So with blended light textures under glass, since they are both blended, setting sort_order to -1 would seem to be pushing the item behind the glass. That works on the Lambo, hmmm...


It probably is mainly a case of splitting shaders/geometry more appropriately so each item can be rendered where it needs to be!

Dave

 

[Stereo]

For any smooth glass surface, reflect needs to be almost 1 to get the mirror appearance at steep viewing angles? (not exactly 1 probably because of tiny roughness or dirt/dust on the surface?)

This is the main thing my window2 shader changes compared to window, actually.

(window2 top, window bottom)
Near perpendicular, the reflection gets much nearer 100% with window2.

Speaking of which, RC5 can't reload shaders because the track just fails. I did this in RC3.

EDIT:
If SORT_BLENDED=600 is blendfunc=blend and SORT_ADDITIVE=900 is blendfunc=add, then we need sort_offset=-300 to get added stuff blending first?
Can't tell if that's what it's describing.

Regardless, one extra vf_standard with blendfunc=add won't kill the framerate, may as well just have an extra shader.

What the rear glows could really use is a z-offset like the flares use, that leaves them in the same place on the model, but renders as if they were closer to the camera. That way the regular lights could be located behind the glass, but then rendered as if in front of it. The problem with actually having them outside the glass is, of course, at angles other than straight on you can see the glow is floating.

 

[Mr Whippy]

Yep, also at steep angles in the right conditions, brake lights glow might disappear under the intense light of the reflection of say a sunset in the glass OVER the brake light.

So doing brake lights is hard. I think having them under the glass makes sense, that is where they are.
Bloom is probably wrong as discussed in another thread... better to use the frame buffer, find stuff out of the current tone-mapped range (whited out basically), and then apply a blur to that then add it back over. Current bloom uses a range of unreal values and weird mixing. I can't see how it's any faster than just blurring a clamped range of the HDR buffer?!



Yes, using add under blended glass would suggest you need a big offset to get it rendering right... ie -300 or more.
If you use values like that though things go weird... well they did in my case... super-bright brake lights and such... not sure why... might just have been something specific to my project at the time but well worth a try again imo!



I think you are right though, split these models into many shaders/dof as possible, get them working, and then start to combine them to see where you can optimise.

Worst case scenario, you only spend 2 batches for all your above glass blended and under glass blended lights, then another 2 batches for brake lights at most when they are on.

Worst case is 4 batches vs 2 batches to do the same job... so not a big problem in my mind.

Even on a course of 10 cars all braking it's 20 batches extra worst case on a night course... I think stuff like projected headlights and stuff are probably gonna be the thing hurting FPS in those situations

Dave

 

[Stereo]

Speaking of lights...

I can't find any reference to reverse lights or turn signals in the documentation. Are those done entirely by script on cars that have them?

 

[Mr Whippy]

I think reverse lights were fudged somehow, 3d model as a reverse gear indicator...

Indicators, I'm sure they were in as a feature, along with high/low beam, but maybe not.

Imo Ruud should either hard code these things or expose enough to Onyx to allow us to do them via scripts.

Dave

 

[Harey]

yeah reverse models can be put in IIRC its something like body.model_reverse or something like that can't remember off the top of my head, and don't have a car.ini to look at on my laptop.

I've seen other people do indicators, but i never have done them myself. (might have been a script someone did, same with high/low beams)

 

[KS95]

IIRC indicators were a feature, but I think most people just use scripts.

 

[Stereo]

yeah reverse models can be put in IIRC its something like body.model_reverse or something like that can't remember off the top of my head, and don't have a car.ini to look at on my laptop.

Heh, tried a couple guesses similar to that, it's body.model_reverse_l body.model_reverse_r.

Probably gonna skip indicators. They do have a variable in views.ini (indicator_left, indicator_right) but I have no idea how to set up a button to activate them or anything to even test it works.

 

[Mr Whippy]

Pretty sure I read about signals or indicators on racer.nl, hmmm.

Might just be imagining it though


Was just thinking about lights again, can we do the glow effect on the road behind the car for brakes etc by using a shader/polygon that hovers above the ground but projects its additive pixel info onto the underlying poly/shader?
In theory you can kinda do this like you have the glow under your headlights on the car body... Issue is just projection parallax... Ie you have transformed those light flare meshes to point at camera, can that be done with a polygon to always point straight down?!

Hmmm...

Or Ruud can just add the light0...999 feature so we can add lights to the back of the car

Dave

 

[Cosmo°]

Indicators are not natively supported via car.ini unfortunately - around four years ago I pestered Ruud about it a few times and he wanted to "look into" adding the model entry, but nothing ever came out of it. For the meantime, in your controller .ini file you can add this:

indicator_left
{
axis=
min=0
max=1000
button=22
pov=-1
negate=0
make_analog=0
linearity=1.000000
sensitivity_rise=0.000000
sensitivity_fall=0.000000
key=
}

...as well the equivalent for the right side. Since this will only activate the views.ini signals and we can still not call out for anything but the keyboard via scripting, the whole thing is pretty limited in its usefullness if you map it to a sensible place like your steering wheel, as I did.

 

[Mr Whippy]

Hmmm, any way to tweak shaders via Onyx?

Could just cycle emission on a texture...

Or turn a model on and off in car.ini?


Oh for Onyx to be exposed to everything

NFS5 had indicators, can't be that hard

 

[Cosmo°]

Turn signals activated via scripts currently move a generic model at the press of a button as you mention it, though only the keyboard is supported as an input source. Hence, you would then have to run your Profiler software on a Logitech wheel for example and link it to that keystroke. Otherwise, you end up with indicators mapped to your controller and still have to fumble around the keyboard while driving...

If you can get away with two-dimensional turn signal textures, views.ini calls plus direct controller button presses would be less hassle for the user, but unfortunately that doesn't apply often.

Maybe it's just time to poke Ruud about it again - and while we're at it, I remember at the time I asked about the indicator models being supported, there was a controller.ini call for highbeams too. Back then, Ruud told me that feature wasn't meant for the internet version and so it disappeared again.

 

[Mr Whippy]

This is why we should just look forward to Onyx feature escalation and improvement so we can manage all this ourselves.

Ruud can the focus on important stuff like diffs and pacejka then, and we can refine functionality like these indicators etc... Stuff that might not be valuable for Ruuds uses of Racer but will benefit us

I guess moving a light model via script is ok only downside is possibly more batches than needed for all the brake lights, not sure if they are culled or cost you in batch count if hidden... Hmmm...
Probably is the best approach on balance though, more so if when hidden the batch count is lower!


Dave

 

[Alex Forbin]

Speaking of lights...

I can't find any reference to reverse lights or turn signals in the documentation. Are those done entirely by script on cars that have them?

Here you go...


model_reverse_r
{
file=reverse.dof
}

Alex Forbin

 

[Alex Forbin]

Sorry to nit pick, but didn't we decide that glass fresnel values were something more like 0.04 0.96 4.5? Using glass IOR to calculate the proper values? Very close to lacquer on car paint, as they are kinda the same material really. Just glass seems to have a stronger power/falloff amount!?

For any smooth glass surface, reflect needs to be almost 1 to get the mirror appearance at steep viewing angles? (not exactly 1 probably because of tiny roughness or dirt/dust on the surface?)



Dave

Wow a sudden burst of activity on the forum.
I must have missed the discussion where the fresnel values for glass were decided. Oh well, I'm not THAT far off anyway. The material shader should be set to reflect=1 since the fresnel parameters just modulate to that value as a max value.
While we're on the subject, I would like some real lighting values for ambient/diffuse/specular
for a few materials. I've been reworking the lighting and have gotten rid of the glowing materials in shadow and some other odd behavior but I need some real values to tune the lighting engine to. I also found an error in the motion-blur calcs that appears to have fixed some strange problems we were having, wheels are still a problem with one of the schemes however. I've been looking at an algorithm that would work for wheels though. The other problem that's been making me crazy is getting rid of the specular in shadow for bump mapped materials such as tires, but I haven't given up.

The taillights...

The lighting changes...

Is anyone else getting tired of the pop-up about the tires! I wouldn't mind but you can't turn the stupid thing off. The floating car problem shouldn't be impossible to fix either, all forces should logically work toward zero energy (except for y-axis) as motion decreases, OK camber would also give some static force but at 0 motion does it matter?

Alex Forbin

 

[Alex Forbin]

Here's an image showing the tire shading problem...

Alex Forbin

 

[Stereo]

Didn't get the whole list checked off, but my vacation's coming to an end and I did hit the major points, so I thought I'd clean it up for distribution.

Mazda RX-7 (3MB)
window2_f.cg shader
Put the shader in racer/data/renderer/shaders/ if you haven't got it, the car in racer/data/cars/.

If you find something wrong that's not listed, let me know. Also feel free to advise changes to the .ini.

 

[foxo]

Well the overall feeling of the car is pretty good. But there are some minor issues that that i have seen.
The steering felt too sensitive, maybe that's just me(using mouse)
The brake rotors glows with calipers while braking
It's doesn't have an RPM limiter, maybe it's the problem with the torque curve.
The interior could get some work, I hope it's gonna be updated someday.
It was a pleasure to ride it.
Thank you, and Happy Holidays!

 

[Stereo]

Whoops, fixed the link.