Messages

Did you try a .tga with an alpha channel? I am sure it works for bike textures as I tried a damaged fairing effect

If we had a true 1P helmet camera it would not be an issue

I was all set for a big overhaul release but the bike physics/tyres are beyond me to get right now so I gave up. New bike would have better paint maps so its easy to do your own. Worked out how to add shaders to the paints as well so you can go mad if you want

Will support be completed to allow the standalone edf exporter to create .anm files?

The interface has an animation name box but it does not appear to function - is the function incomplete or can it only operate from a script of some sort?

Well I have been through most of the range of possible adjustments and nothing appears to really lift the handling into 'believable' territory.
Some observations;
Heavier and more powerful bikes appear worse effected
The bike feels almost 'hinged' in the middle with the rear trying to overtake the front - this becomes massively exagerrated on any sort of incline.
The same occurs on long, fast turns with the bike developing excessive lean and the rear wanting to overtake the front, double apex corners are pretty much out of the question due to the strange lines you end up taking.
Launching off a crest appears to introduce a very significant forward rotation even though the bike is neutrally balanced.

Interesting little experiment;
In the riders\whatever\gfx.cfg change the cockpit model reference to the full model as below;

cockpit
{
   model
   {
      ;file = c_rider.edf
      file = rider.edf
   }

   suit = suit

   helmetlinkobj = riderRIG_Head
}

It is now very ovbious how far away from the riders head the camera is in turns or even when tucking in - the actual model animation looks like he would be right where you would want the camera but the 1P view seems to be locked to a small box of movement.

I really cannot see why we cannot have a view added that just tracks with riderRIG_Head but looks towards the current point of focus as usual. If the camera was kept just in front of the rider eye position we could even have some nice visor visual effects.


Have to say the 'full' model looks better with head tracking than the current cockpit rider model - he has legs.
 

I have been trying to resolve z fighting issues at some points on a larger track without success. Tried new geometry, UV mapping, textures and shaders but the problem persists. It is not just the odd object that might have an intersection issue but the entire scene starts to flicker.

After observing in-game, it almost appears as if the z buffer scaling is constantly flipping between 2 very different values so I am guessing it is something to do with the calaculated depth of the scene.

Any tips for resolving? Out of curiousity what bit depth does GPB use for the buffer?

Thank you.

I guess if you swapped the references in gfx.cfg which should force the change it would be because, selectively, the correct link pivots are not being passed to the animation.

The .anm files can be created directlly from the 3DS edf exporter - so I guess it is just a 3DS animation file converted to PBs .anm

Its a shame we have no information how this is achieved using the standalone exporter.   :-(

Not much help, but from what I can gather they are shape animations much like the shock and cables and generated in 3DS so I guess it uses their output format.

The rigged model is only used as a method for deforming the rider mesh in 3DS to generate keyframes for each move position, these are then strung together like a cartoon. the file is probable just a big list of vertices and their index number.

In game we only have the model mesh of the rider and no bone rig - hence we can never have a 'rag doll' style physics influenced rider

If you multi-map a texture which layers should containg the normal and specular maps or can you have maps for each layer?

Thank you.

Thanks for the reply, that is basically how I had assumed it should work.

In the default .amb clear{} are the values in ambient and sun_color reversed by any chance?

Reversing the blocks so that the values for sun are in ambient and  ambient are in sun looks a lot better and aligns with the scaling between cloudy and rainy.

I know this is an old idea and asked for several times but the exporter is so, so, very, very slow when compiling with shadows its hard to know if its just taking forever or if it has locked up in a loop.

Something simple like 'processing element X of XX' would be OK if a progress bar is too difficult.

Why is shadow processing so slow? Is their anything with the model geometry or lighting position that can be done to improve things?

Track shadows are the only track 'effect' we have and it looks quite ugly and strange if its impossible to add them, I tried adding shadows to a track that takes about 45mins to compile without shadows - after 4 hours of trying to compile with shadows I cancelled the process.

Thank you

Surprisingly wikipedia has some interesting observations;
https://en.wikipedia.org/wiki/Countersteering

So it not really the lean its the torque on the chassis from your legs that initiates the required counter steering then the CoG shift can contribute a bit

Its quite interesting if you think about it in reverse; when we set up for a high speed, high lean turn we get to move our weight to the inside of the turn well before we get there to avoid upsetting things when everything is loaded to the max but the bike does not go into some crazy steering but waits until we initiate the turn at the bars, as we exit we can straighten the bike using bar input before we start to get ourselves more centred on the seat.

Push bikes are not really a very fair comparision, very slow, very light wheels and no engine (crank/box) so you are not trying to overcome a lot of gyroscopic motion.

At very low speed I would suspect that what might occur is you can push the chassis over a bit with enough force, the wheel wants to go straight on so you generate a tiny bit of an angle at the steering head (everything is sort of reversed) which will be in the required countersteer motion to allow precession of the wheel which then allows the wheel to turn a bit. You can see it in the video where the bike sort of drifts off line but its not really steering and at any useful speed the forces in the wheels and engine exceed anything you could generate with a weight move - its why superlight wheels are so desirable and one of the downsides to wankel engines in bikes .

MX jumping is a good display of how much the wheel forces can control direction, they use the brakes in flight to do all sorts of crazy stuff.