Panthera Free V8.12.12 (June 2016)

[Mr Whippy]

I thought it was probably worthwhile adding a specific thread for this version as it'll no doubt get updated and the other thread will become confusing.

So just post things you've spotted, things you've got working, things which don't work or you're having trouble getting working, useful hints/tips etc!

 

[Mr Whippy]

Firstly a few audio notes.
It appears with Fmod likely to be fully implemented in the coming versions of Panthera these may not be priority fixes/updates but I'll add them any way.

shiftin & shiftout{}
These sound sets appear to be played irrespective of in/out camera location, and played at a volume irrespective of camera distance to the car.

throttle_off{}
This sound set is still heavily hard coded (as noted in the Content Developer Guide (CDG)), but would benefit hugely from being enhanced or the variables controlling it being exposed.

engine starter sound
This sound currently plays twice upon starting the engine.
This sound is also still hard coded to use only starter.wav in the root directory of the car. For completeness it'd make sense to allow us to define this sound file, it's volume, and file location.

brake{}
These sounds work ok with an appropriate sample. However it'd be useful to understand what variable is passed to the sound sample to know what natural and min/max values to use.
It's clearly not rad/s wheel speed. Is it instead some internal brake force value?
Is it something we can calculate or view in the debug screens to help tuning the sound and fading etc?

damper{}
These sounds work great for intended purpose! Don't change a thing imo.


A few physics notes:

The MF5.2 pacejka implementation works nicely.

However it wasn't clear what other variables were needed to go with them.
tire_model_front/rear values appear to be entered in the Cruden sample car and default car.ini files, however I thought these were superseded almost a decade ago now?
There were many other values such as max_slip_len, camber_min/max, fz_min/max, slipangle_min/max etc etc.
Is there some definitive guide as to what values are superflous now if we use a full MF5.2 pacejka car?


I've not been able to get the engine{turbo{}} element to work. Given the CDG is saying v8.13 is required I'm assuming this is the case.
I know we can go to many levels of complexity with a turbo, but given many road car implementations these days use a boost control map to limit the influence of the turbo to specific needs, wouldn't it make sense to have a 'max influence' type value?

I'm unsure if Ruud has seen the AC implementation, but it seems pretty basic like this Racer one, but with a maximum pass type filter so the turbo curve can be defined and then trimmed to get the 'feel' that many modern turbo implementations have.

Perhaps a 'type=3' turbo would have a similar system?

Or even type=3 use a .crv file to define the turbo torque_factor vs rpm?



On to graphics:

The car $trackenvmap is rendered from the car origin with the car model present. The car shouldn't be rendered in the $trackenvmap.
I'm mostly intrigued as to how this has been broken since it's worked fine for over a decade despite huge changes to the games graphics engine and so on.
Has anything fundamental changed around envmap rendering to have caused this?


The water shader (used for the waves and sea) doesn't appear to be working. Would it be possible to see some example files if indeed it does work?
I'm looking to use it for road reflections like wet roads/puddles more than a wavy sea or lake.

It'd be good to know if this feature is indeed meant to be a working element of Free Panthera or is limited to the boat sim.



And lastly scripting.

Will there be a definitive list of variables we can access/alter made available?
Currently we have lots of useful scripts for old versions of Racer spread across the original scripting language, then Onyx, and now Panthera generally.
It'd be sad to lose old functionality that isn't replaced, so will it be worthwhile us stating what variables we've used and would like access to in future if they're not already present, to prevent scripting capabilities becoming reduced in future?




Cheers

Dave

 

[Cosmo°]

The unsprung masses still apply a moment around the total mass centre, which causes flipping of vehicles. I used the term "aerial pitch bug" to descibe the effect previously and it has been around for ages. Really needs to be looked into, as this has massive influence on vehicle behavior. For reference, here's one of my previous posts on the topic: http://www.racedepartment.com/threads/racer-v0-9-0-rc8-released.76897/page-3#post-1562589

The default model for combined tyre forces is type=3 for some reason - it used to be 7 and 10 in the previous betas.

The mastervolume in racer.ini is erroneously set to 200, instead of the maximum of 255 by default.

As in v0.9.0 RC10 Panthera/Racer still crashes when trying to access Ctrl+3 on tracks without splines.

Pausing causes all the model files listed in car.ini to be drawn, regardless of actual state, camera/view settings and such.

Adding to the starter sound comments by Dave, the sample is still played in its entirety, even if the user released the input key early.

On top of the envmap issues that Dave mentioned, the general shader engine changes introduced in v0.9.0 RC10 are still undocumented and cause a lot of content to be incompatible, because we can't troubleshoot with the limited qlog info given to us and no idea what was done in the background.

 

[Mr Whippy]

Another possible graphics issue, but I can't seem to get the velocity map to be rendered and used.


I've set the velocity_map=1 in racer.ini.

I've tried the fs_filter1=bloom_shadows_blur_f.cg FS shader and toggled velocity maps and normals on/off, and also the motion blur shader generally and it's not seeming to work.


Is this to do with any recent changes?

Or am I just trying to use it wrong?

It looks like this has been worked on since RC5c or around that time as there is a new motion blur '4' method added to the motion blur fragment shader cg file.


Thanks

Dave

 

[Mr Whippy]

OK another graphics issue I'm having, please say if you don't.

Tyre smoke is missing.



And another feature that seems to have lost some hard coding/flexibility since it was first created. The helicopter camera (settings in racer.ini) seems to have a hard coded settings now, and works not as you'd expect.
Ie, lens FOV seems fixed.
Mass, spring and damping seem to make very little difference as the helicopter is only allowed a few metres either side of the cars ground position until it's dragged along.

Is the bounding box for the camera very small? Could it also have a tunable variable in Racer.ini, along with the other values working?

(best yet have it set per track in special.ini to suit each track if present)

Cheers

Dave

 

[Cosmo°]

Tyre smoke is still present for me, but there seems to be less of it than in previous betas.

 

[Mr Whippy]

Well another graphics issue/bug/change/me doing it wrong

I can't figure out what might be going on but it's not seeming to work.

We *could* reference cube maps (6 faces of a cube) as TGA in place of map= $trackenvmap
http://www.racer.nl/tutorial/reflection_map_creation.htm

Ie,
map=textures\reflections*.tga

Rather than,
map=$trackenvmap (which works for both live envmap, static, old static cube maps from data/images)


This feature was useful for adding reflections to buildings and so on.

I can't seem to get it to work.

Can anyone else get this to work in place of $trackenvmap?



Strangely, if you follow the tutorial exactly, create new cube maps and use the window shaders, then the $trackenvmap is used in the images place.

Even trying to use them on my car, setting the map=track*.tga, then the car somehow gets $trackenvmap loaded.

 

[Harey]

The included session manager was giving me issues, ranging from not letting Panthera start because of a custom vehicle, to not letting Panthera start because of the controller I had selected.

So I switched on the menu in the Racer.ini. and found the car and track menus do not work at all, Panthera will just crash even with the cars or tracks included only installed with the program.

Also noticed the on screen mirror doesn't work, just appears as a wide black box off to one side at the top of the screen.

 

[Mr Whippy]

I had the Session Manager Lite not letting Racer start properly after I swapped my controls to 'g25.ini' via the console.
The g25.ini option was added to the menu, but Panthera wouldn't start once it was selected.


However the solution to this is easy if you use Raven.

Copy the Raven folder to the Panthera folder, delete the main raven.gdb file, start Raven, and it'll ask to point to the racer.exe file.
Simply point it to the panthera.exe file.

This works fine for car/track/controller selections and other options settings still.





I noticed the car/track selection menus don't work at all any more too.

Maybe they're on their way out in favour of a 'launcher' system, which I have no problem with really.
Raven is a launcher that has been in use for ages, and despite small previews of cars it does the job perfectly well vs the 3D garage.

 

[Mr Whippy]

Well the new sky rendering looks quite nice in Panthera, just as it did in the late Racer RC5x versions. The colouring is natural, sunsets look great and correct too vs the old sky.

However the extinction side of things seems quite off.

You notice this when you choose conditions like in the image.

The ground appears to go green, and the sky is clearly pink.

We have to tweak the sun rgb TOD curves to change the green ground to a pink colour, but when we change the TOD sun colour/intensity values to alter the ground extinction, the sky also changes colour too.

This means we can never match the sky appearance to the ground material extinction.

In practice the sun colour/intensity values shouldn't influence the sky appearance, or if they do, then the sky and extinction should at least remain consistently coloured.



So to sum up here. The sky colouring and values look excellent.

The fact tod sun rgb values influence the sky appearance though, and thus likely the extinction inbalance, is what is breaking things.

The sky appearance is driven just by sun position, mie and ray, and extinction factor. This then 'fills' all the other values for tod sun rgb and ambient rgb.

One value drives the other. Sky/sun appearance >> sun/ambient lighting values.

Dave

 

[Mr Whippy]

Ummm I think I found the problem.

GetSkyColor and GetSkyColorAtm are using different functions, which makes sense, but they should be almost the same.


GetSkyColorAtm is used for the sky we see, and is using a very nice sky rendering algorithm.

GetSkyColor is used for extinction, and is using a different sky rendering algorithm.

GetSkyColour doesn't need the 'sun spot' rendering in it because that would then be visible inside objects that the sun passes behind while driving. Due to the sun's very high intensity it would show up even at short distances to objects.


I'm pretty sure this could be fixed quite easily.

I also think the 'inputs' to the decent new sky (the one we see in the actual sky) are quite similar to mie/ray too.
Ie, we should simply be able to adjust this shader to use the ray/mie TOD curves, among some others... rather than hard coding the 'sky' values in atmosphere.ini.


So there is no wonder the sky was doing different things to the extinction



/*
// Ideal fix

Indeed the two outputs could be the same, just don't render the sun spot.

The sun spot should be added to a car via speculars, not the envmap (reflections in shadow still get specular otherwise, and it doesn't conserve energy either!)

The sun visually should then be represented by a 'flare' rendered as a post effect.
*/

Dave

 

[Mr Whippy]

I'm slowly but surely getting where I want to be with this new sky shading.

I've tied in mie/ray appropriately, and edited things so both sky and extinction use the same system.

It works quite ok.

However a few limitations of the 'new' sky system are that mie doesn't work very well to neutralise the extinction colour. In reality this means that high mie (for pollution/large particles like water which make fog) doesn't really create a natural foggy look.

Also as soon as the sun sets, the sky goes dark, so a TOD pass through sunset to darkness looks a bit odd.

It's certainly the best system so far for the sky looking like a real sky, and through a daytime fair weather sweep (so blue sky with clouds etc) and TOD changing, you'll get the best result yet!



BUT, I still think the old atmosphere (for ground materials) gives better tuning parameters for matching real sky textures into the ground haze/extinction in 'interesting' conditions.

Ie, sunrise/sunset, night time (sun under horizon), foggy rainy days etc. It can also create good extinction for normal sunny days too. It was only ever the sky rendering itself which seemed weak (for some reason, maybe a bug or something?!)



At least for now I'd be fine with Ruud keeping the sky system the way it is, because it's quite easy to then add sky textures for the sky, and match them with the old (original) extinction settings... I've been doing this for years and it still looks best.

In an ideal world, and it may be possible after I've done more reading, we could just use whatever we want here and toggle around fairly freely.
Ie, new sky, new extinction... or new sky, old extinction (what we have now)... or custom texture sky, old extinction (what can look amazingly photorealistic).

That would seem to be the ideal approach then as an artist you can achieve whatever look you want.



I think for now though there is no reason for Ruud to change anything here unless he deems it critical, because the system is still flexible enough to get a good look if you need to. It's just a bit unbalanced in extremes where the two sky systems diverge in appearance.

Dave