WIP - Brno Track surface Rebuild.....

[Hawk]

Hi Guys.
Following the success of the "Mallory Park" track surface rebuild, subsequently named "Mallory Park 1978", and also because of subsequent requests to rebuild the "Brno GP" track surface, I've decided to go ahead and start the rebuild of that track surface.

I'll post here with the progress. In the meantime if you have any comments or questions then please post them here in this thread or PM me. Thank you.

[Arvoss]

What's the difference between rebuilding a track and making a track flat? Is it important to rebuild a flat track?

[Alby46]

good to hear that hawk, brno really needs some work just as other tracks

[janaucarre]

Don't understand what do you ask, arvoss.
If a track is really flat, no higher and/or lower point, no rebuild or smoothing is needed, but by me there is no really flat track, and if yes, the track from rfactor are never flat, there is ever bumps, so it needs smoothing. A 2cm bump is bad for gpbikes.

[Arvoss]

Don't understand what do you ask, arvoss.
If a track is really flat, no higher and/or lower point, no rebuild or smoothing is needed, but by me there is no really flat track, and if yes, the track from rfactor are never flat, there is ever bumps, so it needs smoothing. A 2cm bump is bad for gpbikes.

Brno GP has been smoothed and it's perfect now imo. There is still that annoying corner that can't be fixed by smoothing it.

[Hawk]

What's the difference between rebuilding a track and making a track flat? Is it important to rebuild a flat track?

In my opinion, and not all will agree, but I think you might as well rebuild the track or the section of track that is giving you problems, and not try and smooth it. Rebuilding the surface simply gives you total control of the outcome. It's like the analogy of: "Do you try and seal a leaky pipe or do you replace the pipe with a new one?" Which would you do? Which do you think would give the best result?

[Hawk]

Sorry guys..... I've been testing replacing sections of the Brno GP track most of today with just the Brno gp.trp file. I keep getting core.exe's each time I try and replace a section of track. I think it has to do with the fact that the original .map file is trying to apply a material/texture on the new section I replace which isn't there. I think I would need the original texture files which I don't have. so unless someone can suggest another way to use the .trp file without exporting a .map file to do this job then we are stuck and will have to put resurfacing Brno GP on hold for now until we can either have access to the original source file, or decide to totally rebuild the circuit as a whole.

Anyone got any other suggestions how to do this with only the use of the Brno gp.trp file?

[Hawk]

Just so you can see..... Here is the section of track that was giving riders big problems that I rebuilt and replaced today.

[Ian]

Thanks for trying Hawk_UK
Did you spot any obvious problems that made it so easy to crash there?

[Hawk]

Thanks for trying Hawk_UK
Did you spot any obvious problems that made it so easy to crash there?

Hi Ian.
There is a slight ridge on that corner enough to upset the balance of a bike leaned right over going around that corner. In my opinion it does need a section rebuild at the very least around most of the corner complexes, and also needs the terrain edging of the track lifting up level with the track surface. This is the very least that needs doing.

Thanks Ian. 

[HornetMaX]

Hawk, do you have the same wireframe image of the original track ? just to see the differences.

MaX.

[Hawk]

Hawk, do you have the same wireframe image of the original track ? just to see the differences.

MaX.

I can soon create one Max.... I'll post later. 

[Hawk]

Hawk, do you have the same wireframe image of the original track ? just to see the differences.

MaX.

Original track surface pic before the rebuild. I've angled it so you can see the ridge on the inside of that problem corner.

[HornetMaX]

Hmmm ... just a wild guess maybe, but I'm under the impression that GPB "dislikes" when the track is describes by "rectangles split into two triangles".
Probably this is fine when the two triangles are in the same plane, but if the track has slope/banking, this may no longer be the case and could cause problems.
Or maybe it is a problem of having polygons that are too "thin" somewhere.

I could just be utterly wrong, so be critical.

Imagine you have a very short straight section of the track to model, let's say 7 meters wide, 2 meters long:

Code Select Expand


L2---------------------R2
|                      |
|                      |
L1---------------------R1


If the left and right border lay in the same plane (which may or may not be horizontal, btw), you can cover this section with a (flat) rectangle (L1-L2-R2-R1-L1) or you can split the rectangle into two triangles using one of the diagonals (L1-L2-R2-L1 and L2-R2-R1-L1). This should make absolutely no difference in terms of end result in-game.

However, if the two borders are not co-planar you cannot use a rectangle (as a rectangle is flat). However you can still use the two triangles I mentioned above, but the two triangles would not be coplanar. That's not a big issue in fact, but is the two borders are skewed a lot you may end up with one triangle's tip (the vertex with the smallest angle) having a relatively steep angle (compared to the plane of the adjacent triangle) and being very thin. That combo is probably bad (for reasons linked to the integration of the dynamics). Or maybe its just the ridge that is create don the diagonal (or a combo of the two effects).

I'd try using rectangles only on the entire track, just like hawk did. Notice that you need more than one rectangle to cover the track width only if the track has some camber there: if it's flat, one rectangle spanning the whole width should be OK.

Just rambling, I'm really no expert in this stuff.

MaX.

[Hawk]

@Max:
The 2nd picture shows mostly Tri's not Quads because when a track is originally ripped the quads have been transformed into tri's for the graphics card to render, and the ripper software takes the triangulated rendered data and not the original quadrated mesh that was modelled. No modeller models in tri's because they are a pain in the ass to work with compared to quads. So to visualize the scene as modelled in the second picture, just ignore the diagonal edges splitting the quads.
However having said that, you can see from that picture that someone has replaced sections of the track surface with quadrated mesh since the rip.

Basically from what I was taught when modelling a track surface, was that because of the way the collision detection model often works with most track dev's, it is a must to have a minimum resolution of poly's spanning the width of a track. This is for stability during collision detection. I was taught to have a minimum of 3 quads spanning the width of a flat track surface, and you increase that with the complexity of the angle of the turn, camber, or for modelling depressions, or rises, etc, etc. But the topology of the quads in the track surface you are modelling must be uniformly spaced across the whole section of track your are modelling(I'm trying not to confuse or create mistake in understanding here, like I did with Ricco). If you are modelling a corner section and it needs a high resolution of quads then that section must be modelled uniformly for the whole of that section.

To me Gp Bikes seems to need a particularly high resolution of quads in tight corners especially to maintain stability of a model on track while cornering a tight bend. I have no idea why? Maybe because as Piboso has said, that the physics still need some work on them to finish? Maybe once the physics are finalized, the tracks could stand a lot less quad resolution and still maintain stability of the models traveling across the track surface, particularly noticeable in tight bends and when making quick direction changes as in a chicane for example? I don't know.

Yes. It stands to reason that if you have a track surface with just one quad spanning the width, that if you then have a depression, rise, or camber to model in that section of track it will cause problems because the resolution isn't there to smooth out that transition from flat to angled track surface.  After all, no track surface is flat, not even a straight. So to model like we mostly see in a lot of these tracks is a technique from the early days of track surface modelling when lack of CPU/GPU speed and memory size were the biggest hurdles to overcome. Maybe that's the era a lot of these tracks come from? Who knows. 

Hope I understood you correctly, Max?