Possible Track Collision Detection Instability??

[Hawk]

I've just been doing some work and testing on the Assen TT 2015 track I'm creating and I've definitely found a correlation between low poly track meshes and bike front end instabilities(Shaking and lowsiding). Seems to really start effecting bikes when the poly count gets down to 3X3 on the corners, particularly if those corners have any camber or banking.
The more I raise the poly-count to the track mesh, the smoother the bike rides on those track surface corners. Just got me thinking if the collision detection is the problem here?

Also find that the higher I raise the poly-count the processing time taken by the 3ds Max EDF exporter plugin for the .map file increases dramatically, .trp seems not affected. Which I suppose this makes sense, but just thought I'd mention it. 

Hawk.

[grimm]

During one of the physics discussions a year or two ago (maybe three?  ), I recall bringing up the same thing about certain tracks having a bit of an issue with the bike seeming to have a riding over speed bumps in a corner type oscillation to the front end as you pass through a corner on some tracks more than others. Was told it was all in the bike or sim physics and it had nothing to do with the track... seems I may have just not been able to describe it well enough as what you are finding sounds like the same thing I described way back when.

I've noticed the smoother Victoria got the smoother the bikes were, but using the same old tracks produces the same old results, just that it gets less apparent (better?) with more physics improvements by Piboso. Good to know there is help for the head shakes yet. Some of the tracks that produce the issue alot are some of the more fun circuits as well. Hopefully this brings modders a new way to construct tracks to be compatible with the bikes so true to life lap times are more possible on more venues. 

[Hawk]

During one of the physics discussions a year or two ago (maybe three?  ), I recall bringing up the same thing about certain tracks having a bit of an issue with the bike seeming to have a riding over speed bumps in a corner type oscillation to the front end as you pass through a corner on some tracks more than others. Was told it was all in the bike or sim physics and it had nothing to do with the track... seems I may have just not been able to describe it well enough as what you are finding sounds like the same thing I described way back when.

I've noticed the smoother Victoria got the smoother the bikes were, but using the same old tracks produces the same old results, just that it gets less apparent (better?) with more physics improvements by Piboso. Good to know there is help for the head shakes yet. Some of the tracks that produce the issue alot are some of the more fun circuits as well. Hopefully this brings modders a new way to construct tracks to be compatible with the bikes so true to life lap times are more possible on more venues. 

I have a feeling that most of the converted tracks for GPB came from sims that ran cars? I would say collision detection for car sims is a lot more forgiving, whereas a bike-sim probably has to have a higher accuracy of collision detection to run the bikes very stable on the track surfaces?

I don't know about what you think Grimm, but I would say at least 70%, if not more, of the tracks we have for GPB could do with their track surfaces re-building? Shame we haven't got the 3D scene files for them all.

Hawk.

Hawk.

[HornetMaX]

Seems to really start effecting bikes when the poly count gets down to 3X3 on the corners

What do you mean 3x3 ?

[Hawk]

Seems to really start effecting bikes when the poly count gets down to 3X3 on the corners

What do you mean 3x3 ?

It's the poly density grid for the track surface - Taking a one poly width slice of the track surface = (3 poly columns) x (track width of 3 ploy). 

Hope that helps mate, but I can post a pic if you cannot picture my explanation? 

Hawk.

[HornetMaX]

Pic please

I'd say it depends how big (in meters) is the slice, in both width and length.

[Hawk]

Pic please

I'd say it depends how big (in meters) is the slice, in both width and length.

Here you go Max. 

Track Grid 3x3JPG by Hawk_GB, on Flickr

Hawk.

[HornetMaX]

So essentially you're saying the a 3 poly width (to cover the whole track width) is often not enough, right ?

I got confused by the "3x3", I don't see what the other 3 refers to.

[Hawk]

So essentially you're saying the a 3 poly width (to cover the whole track width) is often not enough, right ?

I got confused by the "3x3", I don't see what the other 3 refers to.

Well it's a little more complicated than that, because it depends on the detail you want in the track surface(including straights). If you just want the bare basics on a flat/ish track then I'd suggest probably a 3x3 density throughout. But if you have a track surface with greater differences in height throughout the track, Like "Cadwell Park", even I'd say "Victoria" in places.  then I'd suggest maybe low poly densities(3x3) on the flatter straight sections and higher poly densities on corners and hills, especially on corners that have any larger cambers or banking or tight turning angles(hairpins for instance).
But then if you wanted to add even more detail to the track surface. ie: Random bumps and undulations then I'd suggest a high poly density throughout the track whole track surface mesh to be able to model those.

But as I said in my first post: The instability "seems to really start effecting bikes when the poly count gets down to 3X3 on the corners, particularly if those corners have any camber or banking.  Increasing the track surface poly count density seems to certainly tame those instabilities from the tests I've done.

But I'm wondering if this is down to an instability with the collision detection in GPB?

Hawk.

[grimm]

Well it's a little more complicated than that, because it depends on the detail you want in the track surface(including straights). If you just want the bare basics on a flat/ish track then I'd suggest probably a 3x3 density throughout. But if you have a track surface with greater differences in height throughout the track, Like "Cadwell Park", even I'd say "Victoria" in places.  then I'd suggest maybe low poly densities(3x3) on the flatter straight sections and higher poly densities on corners and hills, especially on corners that have any larger cambers or banking or tight turning angles(hairpins for instance).
But then if you wanted to add even more detail to the track surface. ie: Random bumps and undulations then I'd suggest a high poly density throughout the track whole track surface mesh to be able to model those.

But as I said in my first post: The instability "seems to really start effecting bikes when the poly count gets down to 3X3 on the corners, particularly if those corners have any camber or banking.  Increasing the track surface poly count density seems to certainly tame those instabilities from the tests I've done.

But I'm wondering if this is down to an instability with the collision detection in GPB?

Hawk.

We're totally on the same page, just that you know faaaar more about this than I do. I have trouble using the right terms and descriptions. Like a gifted rider that hasn't a clue about turning a wrench. 

I think the correct wording is poly count? The higher the count of poly's, triangles, or panels, or whatever each piece of surface is, the smoother the section of track? The rFactor conversions seemed to have the worse bumps in the corners, and scratch made tracks for GP Bikes had the smoothest corners, so it probably was down to the amount of detail in the sections where the track changed elevation or turned.

Example image I found on google that shows the higher detail level in corners versus the strait sections:





Please forgive my lack of knowledge on the subject, I tried to build a track for RBR back in 2007 with Bobs Track Builder, and got the road (2 mile stretch of local road) put together but couldn't figure out anything else. Tried to figure out 3D modeling programs but was lost in all the instructions to a point I have given up multiple times. I'll just stick with building motorcycle frames and tuning carburetors. 

[HornetMaX]

Hawk, what you're not saying is: 3 poly (longitudinally) for how many meters ?

[Hawk]

Hawk, what you're not saying is: 3 poly (longitudinally) for how many meters ?

You can set the size of the poly's to whatever you like; the density of the poly count is what matters to a modeller and not the literal size, but the higher you set the size of the poly's, the less ploy density count you have in a given surface area.

Look at it like this: If you wanted to model a bump in the track, a single ploy just won't do it. You'd need a higher density of poly's to be able to model that bump in the road; the actual size of the poly's doesn't matter so long as the density of the poly count within that given area allows for the modelling of the bump. 

What does seem to matter is the density and uniformity of poly's for stable collision detection(The 3d mesh is often used to create the collision detection model). 

Hawk.

[HornetMaX]

Uh, I do get that Hawk, but 3x3 is not a density. If you say 3x3 is not enough to cover a track section that is 10m wide by 6m long then yes, now you have a density.

[Hawk]

Uh, I do get that Hawk, but 3x3 is not a density. If you say 3x3 is not enough to cover a track section that is 10m wide by 6m long then yes, now you have a density.

I thought that's what I was explaining? That a 3x3 was not enough density(for stability) to cover the Assen TT 2015 track, like I explained in my first post.

Or are you wanting the total number of poly's for the whole track surface of Assen TT 2015 at 3x3? In that case a 3x3 gives a total of 4000 ploy's if I remember rightly off-hand.

Hawk.

[HornetMaX]

I'm just saying that you can't say "3x3 is not enough": it depends on the width and length you're trying to cover. 3x3 is surely enough if you're trying to cover s 10cm by 10cm square.
Or are you saying that polys that are 3m by 3m are not enough ? It's just unclear (at least to me).