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. :P
Hawk.
During one of the physics discussions a year or two ago (maybe three? :o ), 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. :)
Quote from: grimm on November 07, 2015, 11:56:40 PM
During one of the physics discussions a year or two ago (maybe three? :o ), 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.
Quote from: Hawk on November 07, 2015, 11:05:42 PM
Seems to really start effecting bikes when the poly count gets down to 3X3 on the corners
What do you mean 3x3 ?
Quote from: HornetMaX on November 08, 2015, 10:27:39 AM
Quote from: Hawk on November 07, 2015, 11:05:42 PM
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.
Pic please :)
I'd say it depends how big (in meters) is the slice, in both width and length.
Quote from: HornetMaX on November 08, 2015, 01:35:51 PM
Pic please :)
I'd say it depends how big (in meters) is the slice, in both width and length.
Here you go Max. ;)
(https://farm1.staticflickr.com/698/22454472598_19b74ed471_o.jpg) (https://flic.kr/p/Ade3ph)Track Grid 3x3JPG (https://flic.kr/p/Ade3ph) by Hawk_GB (https://www.flickr.com/photos/123824368@N08/), on Flickr
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.
Quote from: HornetMaX on November 08, 2015, 02:42:26 PM
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.
Quote from: Hawk on November 08, 2015, 03:25:01 PM
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. ;D
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:
(http://sipon.fr/docs/mugello/MugelloPanelsScale.jpg)
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. ;)
Hawk, what you're not saying is: 3 poly (longitudinally) for how many meters ?
Quote from: HornetMaX on November 08, 2015, 04:17:57 PM
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.
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.
Quote from: HornetMaX on November 08, 2015, 05:24:21 PM
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.
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).
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'
Quote from: HornetMaX on November 08, 2015, 06:35:23 PM
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. ;D
Hawk.
Quote from: h106frp on November 08, 2015, 06:54:06 PM
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! ;D
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.
Quote from: Hawk on November 08, 2015, 10:34:48 PM
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.
Quote from: Hawk on November 08, 2015, 10:34:48 PM
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.
Quote from: HornetMaX on November 09, 2015, 08:07:40 AM
Quote from: Hawk on November 08, 2015, 10:34:48 PM
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.
Quote from: Hawk on November 08, 2015, 10:34:48 PM
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.
Quote from: Hawk on November 09, 2015, 09:54:39 AM
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 ?
Quote from: HornetMaX on November 09, 2015, 09:58:00 AM
Quote from: Hawk on November 09, 2015, 09:54:39 AM
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.
Quote from: Hawk on November 09, 2015, 03:47:35 PM
Quote from: HornetMaX on November 09, 2015, 09:58:00 AM
Quote from: Hawk on November 09, 2015, 09:54:39 AM
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.
Quote from: HornetMaX on November 09, 2015, 04:07:57 PM
Quote from: Hawk on November 09, 2015, 03:47:35 PM
Quote from: HornetMaX on November 09, 2015, 09:58:00 AM
Quote from: Hawk on November 09, 2015, 09:54:39 AM
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 ;D
Hawk.
Quote from: Hawk on November 09, 2015, 06:01:42 PM
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 :)
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.
Quote from: Hawk on November 09, 2015, 07:27:21 PM
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 ...