Possible Track Collision Detection Instability??

[h106frp]

Is it that the mesh describes a 'solid' ? So as long as you do not need any more detail (i.e. its flat) you do not need any more vertices but say where a gradient change is involved you need 'a lot' to give a smooth curve'

[Hawk]

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).

Okay, I think I know were the misunderstanding is here...... Let me say that the track is 3 uniform poly's in width, including the corner sections. This is making the corner sections unstable for the bike. If I then increase the number of ploy's so that the mesh on the corner sections is now 10 uniform poly's in width the bikes become stable while cornering.

But stop thinking you need to know the size of each individual poly, you don't. You just fill the uniform poly count until you have the density of poly's you need for a given track length or track section your working on to be able to model accurately what you want to model, or additionally in this case to provide the bike stability needed. 
But for sure, on the "Assen TT 2015" track I'm working on, the corners start to become really unstable for bikes at 3 uniform poly width; this is what makes me think it has something to do with the collision detection. The collision detection stability is all I'm querying here in this thread and nothing more. 

I hope that is clearer this time?  Otherwise I give up! Lol. 

Hawk.

[Hawk]

Is it that the mesh describes a 'solid' ? So as long as you do not need any more detail (i.e. its flat) you do not need any more vertices but say where a gradient change is involved you need 'a lot' to give a smooth curve'

Exactly! 
Just that in this case, adding more poly's(Quads made of 4 vertices in this example), not for more detail, but to add more stability for the bikes in the corners, which it definitely does. Again, this is why I'm querying the collision detection stability in GPB. Maybe it just needs optimising or something? Or maybe it just does need more poly density in a given space for stability? I don't know?

Hawk.

[HornetMaX]

Okay, I think I know were the misunderstanding is here...... Let me say that the track is 3 uniform poly's in width, including the corner sections. This is making the corner sections unstable for the bike. If I then increase the number of ploy's so that the mesh on the corner sections is now 10 uniform poly's in width the bikes become stable while cornering.

But stop thinking you need to know the size of each individual poly, you don't. You just fill the uniform poly count until you have the density of poly's you need for a given track length or track section your working on to be able to model accurately what you want to model, or additionally in this case to provide the bike stability needed. 

Which is the same: raising the poly count or lowering the poly size boils down to the same thing.

But for sure, on the "Assen TT 2015" track I'm working on, the corners start to become really unstable for bikes at 3 uniform poly width; this is what makes me think it has something to do with the collision detection. The collision detection stability is all I'm querying here in this thread and nothing more. 

I don't think this indicates a problem with collision detection: it's just that where the track transitions from flat to sloped (or banked) if you have a low poly count the "angle" between one poly and the next may be too big (which means that the track as approximated by the polys is "too discontinuous").

As a confirmation: if you have an absolutely flat turn (no slope, no banked), you don't have stability problems even with low poly count, right ?

Bottom line: for track sections that are sloped and/or banked you need a higher poly count to avoid the track being "too discontinuous" (or "not smooth enough"). This is something you've already proven plenty of times with your smoothed tracks, but I don't think it's a collision detection bug. It's just that the approximated track needs to be smooth enough to avoid "feeling the passing from one poly to the next".

Actually, if in GPB the bike gets "unstable" on low poly turns, it's a good sign: a real bike on a track made of too few polys would be "unstable" too.

[Hawk]

Okay, I think I know were the misunderstanding is here...... Let me say that the track is 3 uniform poly's in width, including the corner sections. This is making the corner sections unstable for the bike. If I then increase the number of ploy's so that the mesh on the corner sections is now 10 uniform poly's in width the bikes become stable while cornering.

But stop thinking you need to know the size of each individual poly, you don't. You just fill the uniform poly count until you have the density of poly's you need for a given track length or track section your working on to be able to model accurately what you want to model, or additionally in this case to provide the bike stability needed. 

Which is the same: raising the poly count or lowering the poly size boils down to the same thing.

But for sure, on the "Assen TT 2015" track I'm working on, the corners start to become really unstable for bikes at 3 uniform poly width; this is what makes me think it has something to do with the collision detection. The collision detection stability is all I'm querying here in this thread and nothing more. 

I don't think this indicates a problem with collision detection: it's just that where the track transitions from flat to sloped (or banked) if you have a low poly count the "angle" between one poly and the next may be too big (which means that the track as approximated by the polys is "too discontinuous").

As a confirmation: if you have an absolutely flat turn (no slope, no banked), you don't have stability problems even with low poly count, right ?

Bottom line: for track sections that are sloped and/or banked you need a higher poly count to avoid the track being "too discontinuous" (or "not smooth enough"). This is something you've already proven plenty of times with your smoothed tracks, but I don't think it's a collision detection bug. It's just that the approximated track needs to be smooth enough to avoid "feeling the passing from one poly to the next".

Actually, if in GPB the bike gets "unstable" on low poly turns, it's a good sign: a real bike on a track made of too few polys would be "unstable" too.

I know were your coming from in your thinking on that Max, but I've tested that too but found it to be an incorrect assessment. The only other thing it can be down to is either collision detection or bike physics, but ruled out the bike physics being the problem because of the sudden stability when increasing the poly density.

3 or 4 poly width for basic track modelling should be perfectly fine and stable for most corner builds, even with camber and slight banking.

Hawk.

[HornetMaX]

I know were your coming from in your thinking on that Max, but I've tested that too but found it to be an incorrect assessment. The only other thing it can be down to is either collision detection or bike physics, but ruled out the bike physics being the problem because of the sudden stability when increasing the poly density.

3 or 4 poly width for basic track modelling should be perfectly fine and stable for most corner builds, even with camber and slight banking.

If there's no problem with (let's say) 6-10 poly width but there's a problem with 3-4, then it can't be a collision detection issue, as collision detection works the same no matter the poly width.
When you say: "3 or 4 poly width for basic track modelling should be perfectly fine and stable for most corner builds", what are basing yourself on to affirm that ?

[Hawk]

I know were your coming from in your thinking on that Max, but I've tested that too but found it to be an incorrect assessment. The only other thing it can be down to is either collision detection or bike physics, but ruled out the bike physics being the problem because of the sudden stability when increasing the poly density.

3 or 4 poly width for basic track modelling should be perfectly fine and stable for most corner builds, even with camber and slight banking.

If there's no problem with (let's say) 6-10 poly width but there's a problem with 3-4, then it can't be a collision detection issue, as collision detection works the same no matter the poly width.
When you say: "3 or 4 poly width for basic track modelling should be perfectly fine and stable for most corner builds", what are basing yourself on to affirm that ?

I'll see if I can do a test build for you to demonstrate.... Probably "Mallory Park 78_Test" would be a good track with it's tight camber uphill hairpin and the other long flowing corners and dips. 

Hawk.

[HornetMaX]

I know were your coming from in your thinking on that Max, but I've tested that too but found it to be an incorrect assessment. The only other thing it can be down to is either collision detection or bike physics, but ruled out the bike physics being the problem because of the sudden stability when increasing the poly density.

3 or 4 poly width for basic track modelling should be perfectly fine and stable for most corner builds, even with camber and slight banking.

If there's no problem with (let's say) 6-10 poly width but there's a problem with 3-4, then it can't be a collision detection issue, as collision detection works the same no matter the poly width.
When you say: "3 or 4 poly width for basic track modelling should be perfectly fine and stable for most corner builds", what are basing yourself on to affirm that ?

I'll see if I can do a test build for you to demonstrate.... Probably "Mallory Park 78_Test" would be a good track with it's tight camber uphill hairpin and the other long flowing corners and dips. 

No no, stop ! I do trust you that with 3 it doesn't work well, I don't need to verify that (don't waste your time on the test track).

What I'm asking is: why do you believe that with 3 it should work fine ?
Most likely with 3 it can't work as expected because 3 is simply not enough: the resulting mesh is too irregular to have a bike running on it smoothly with a decent lean angle.

[Hawk]

I know were your coming from in your thinking on that Max, but I've tested that too but found it to be an incorrect assessment. The only other thing it can be down to is either collision detection or bike physics, but ruled out the bike physics being the problem because of the sudden stability when increasing the poly density.

3 or 4 poly width for basic track modelling should be perfectly fine and stable for most corner builds, even with camber and slight banking.

If there's no problem with (let's say) 6-10 poly width but there's a problem with 3-4, then it can't be a collision detection issue, as collision detection works the same no matter the poly width.
When you say: "3 or 4 poly width for basic track modelling should be perfectly fine and stable for most corner builds", what are basing yourself on to affirm that ?

I'll see if I can do a test build for you to demonstrate.... Probably "Mallory Park 78_Test" would be a good track with it's tight camber uphill hairpin and the other long flowing corners and dips. 

No no, stop ! I do trust you that with 3 it doesn't work well, I don't need to verify that (don't waste your time on the test track).

What I'm asking is: why do you believe that with 3 it should work fine ?
Most likely with 3 it can't work as expected because 3 is simply not enough: the resulting mesh is too irregular to have a bike running on it smoothly with a decent lean angle.

Okay Max. No probs as I haven't started it yet. 

The reason I think that 3 should work fine is that with a 3 poly width flat corner track surface the bike runs okay, but as soon as you put any bank or a +/- camber on it, and that doesn't alter any angle between each individual poly edge, so each ploy is as flat as it was relative to each other as it was when the track surface was flat, the bike now starts to become unstable. The tighter the corner the more unstable the bike becomes at 3 poly width. Flatten the corner again and it's stable again.

Now if I increase the poly density to let's say 10+ poly width on the same corner and apply the same bank or +/- camber angle, the bike is stable and smooth as silk.

The premise that by applying banking or a positive camber to the poly's creates a + or - angle between each poly edge in the track surface just cannot happen with the way it's applied. Now if you were to apply bumps or a camber curve were the track surface peaked in it's centreline and tailed off slightly to the left/right of the track surface, then I'd agree and say that with a low poly width it could happen to create peaks and dips at the poly edges, but that would naturally require a higher density of poly's to model those shapes smoothly into the track surface.

If you take a ride around the Mallory Park 78 hairpin(if you have not already done so in beta 7b) you'll find that it's no problem now that Piboso has work on the bike physics. The hairpin track mesh has not been changed since Beta 5 I think it was, yet in beta 6c the bikes were having a problem with stability around that hairpin. In beta 5 the bikes were stable. Now in beta 7c the updated bikes are now stable again, even more stable I think than before in beta 5.

I hope I've explained that well enough. Lol 

Hawk.

[HornetMaX]

Okay Max. No probs as I haven't started it yet. 

The reason I think that 3 should work fine is that with a 3 poly width flat corner track surface the bike runs okay, but as soon as you put any bank or a +/- camber on it, and that doesn't alter any angle between each individual poly edge, so each ploy is as flat as it was relative to each other as it was when the track surface was flat, the bike now starts to become unstable.

The part above in bold is wrong. A banked straight is geometrically flat (i.e. lies on a plane), so the number of poly doesn't matter.
But a banked corner is not flat: the smaller the number of polys, the higher angle you have between consecutive polys (consecutive in the direction of travel, not laterally).

That's the same reason that when once Piboso corrected me saying that "GPB has a problem with corners on slopes, not with banked corners" (as I said) I replied that the two things are basically identical because when you have a banked corner and you "run wide" on it, you're climbing up a slope (the dual is true too, of course).

After that, the diffrences in physics between b7 and b6 may make the problem more or less visible: I'm still convinced that the virtual rider in b6 was reacting "too much" and with a torque that had too much "high frequency" content. This could make it do strange things on tracks that are not smooth enough. In b7 the virtual rider seems much "quiter" in low speed corners, so this could explain that.

So forget about chasing a bug that most likely is not there. But keep on smoothing tracks, where necessary

[Hawk]

I'm sure I know what your talking about now, but the angle your talking about is minute even on a 3 poly width surface unless you start banking at a high level like for example the Daytona banking. I'm sure the minute difference wouldn't, or shouldn't create such an instability; the fact that it does should call for an investigation to make sure nothing is amiss?

Hawk.

[HornetMaX]

I'm sure I know what your talking about now, but the angle your talking about is minute even on a 3 poly width surface unless you start banking at a high level like for example the Daytona banking. I'm sure the minute difference wouldn't, or shouldn't create such an instability; the fact that it does should call for an investigation to make sure nothing is amiss?

I don't think the effect is as small as you're saying ... not a lot of banked turns, but there are decent slopes around: victoria hairpin, catalunya, ...

But do we need to investigate it ? I mean, with 5 (or whatever) polys beta6 was almost fine. Now beta7 seems to be fine. if with 3 we have troubles, we should just avoid having 3.
I wouldn't know where to start in digging into this (even having the source code at hand). But maybe Piboso can work something out, don't know ...