• Welcome to PiBoSo Official Forum. Please login or sign up.
 
March 28, 2024, 12:17:43 PM

News:

GP Bikes beta21c available! :)


(WIP)Mallory Park Track Surface Rebuild TEST...

Started by Hawk, April 13, 2014, 06:53:25 PM

Previous topic - Next topic

Hawk

April 13, 2014, 06:53:25 PM Last Edit: September 27, 2014, 09:59:11 PM by Hawk_UK
Hi Guys.

Updated on Wednesday 18th June 2014:

Mallory Park 1978 V1.1 is now released and available to use online. You can therefore now obtain this track from the "Track Downloads" Database here: http://forum.piboso.com/index.php?topic=45.0


Thank you for all your support and comments while working on this great little track. I hope this thread will continue to be of use to those that wish to alter or create a track of their own. Thank you. ;) ;D 8)



I've been talking about track topology and why I think bad topology has a lot to do with why bikes react in a weird way sometimes, particularly in chicanes and corners when bikes seem to fall over for no good reason.

Well I thought I would test my theory and rebuild a track surface to see if this would improve the bike handling on track. So I decided to rebuild the "Mallory Park" track surface this afternoon.

Below I have posted some photo's, of before and after, to demonstrate the difference in track surface topology(Ignore the original topology of the rest of the track surroundings, it's all terrible, but I only wanted to test the track surface itself. :)

BEFORE:






AFTER:







I've still got some cleaning up to do, and then I've got to start the GP BIkes integration process..... Would love some help to integrate this track so we can test it..... So if you can help then let me know, and then as soon as I've finished cleaning it up I'll send it to you for integration, otherwise I'm going to have to work it all out for myself and that will take longer... Much longer. Hehe ;D


Either PM me, or post here if you can help me integrate this test track into GP Bikes. Thanks. ;)



PeterV

April 13, 2014, 08:28:07 PM #1 Last Edit: April 14, 2014, 02:49:05 PM by PeterV
well that looks like a class a job Hawk, very clean tracksurface the way you build that up.
I'm curious how it drives compared to the old one, i feel a test coming up. ;D

Nice one.

Arvoss


C21

You visulazied what i feel driving through corners on some tracks.
It feels like im driving above every single line through the corners...
Interested how it feels driving the updated track....
# Member of the CAWS Racing Team #


SA_22

yea definatley the right way about it... honestly you could probably get away with afew more tri's in the corners.

some thing i have found out while working out the tools, is the collision seems to be a heavily optimized version of the surface ( even the track) so that could also be apart of the problem.

for example the lighting test i posted a pic of in my question thread.. the sphere has the track id texture etc... but the collision is pretty much a box inside of it.

really need to find out exactly what the collision export is doing to work out how to build a perfect track... or find a way to import or own collision file!

HornetMaX

Quote from: SA_22 on April 14, 2014, 11:34:05 AM
yea definatley the right way about it... honestly you could probably get away with afew more tri's in the corners.

That would be my advice too. The old topology has probably been done by a mad man with at least 5 gr/l of alcohol in the bloodstream, but in your one too few polys may lead to strange handling too.

MaX.

Hawk

Quote from: SA_22 on April 14, 2014, 11:34:05 AM
yea definatley the right way about it... honestly you could probably get away with afew more tri's in the corners.

some thing i have found out while working out the tools, is the collision seems to be a heavily optimized version of the surface ( even the track) so that could also be apart of the problem.

for example the lighting test i posted a pic of in my question thread.. the sphere has the track id texture etc... but the collision is pretty much a box inside of it.

really need to find out exactly what the collision export is doing to work out how to build a perfect track... or find a way to import or own collision file!

Quote from: HornetMaX on April 14, 2014, 02:40:40 PM
Quote from: SA_22 on April 14, 2014, 11:34:05 AM
yea definatley the right way about it... honestly you could probably get away with afew more tri's in the corners.

That would be my advice too. The old topology has probably been done by a mad man with at least 5 gr/l of alcohol in the bloodstream, but in your one too few polys may lead to strange handling too.

MaX.

@Max/SA_22: Well this is what the test is all about guys..... Whatever the test reveals it will be easy to increase the polygon quad count if needed because of the possible issues you've suggested, but until we know what techniques Piboso is using for collision detection for the track surface we really don't know. :)

I can always create a high resolution quad track surface to compare if we get any problems..... Let's just test this and see what difference it will make first and take it from there. ;)

RiccoChicco

April 14, 2014, 10:37:20 PM #7 Last Edit: April 14, 2014, 10:39:21 PM by RiccoChicco
You don't need to create a very high poly track surface, it will be too heavy for the game. You only need to have enough polys in corners where you take a lot of angle. The easier way to know, is to have a "low poly" track surface, and to see where you fall after the first export.


Then, you detach the falling turn, you smooth it (here a turbosmooth should be good, with only 1 iteration to start) and you export the track again. If you still fall increase the turbosoomth iteration 1 by 1.

Don't forget that a high poly zone of a track = FPS decreasing while in the zone. Try to make the track as light as possible, so if you can save some polys, do it  ;D


Hawk

Quote from: PeterV on April 13, 2014, 08:28:07 PM
well that looks like a class a job Hawk, very clean tracksurface the way you build that up.
I'm curious how it drives compared to the old one, i feel a test coming up. ;D

Nice one.


Thanks Peter

Once the test track is finished and initially pre-tested for any obvious errors, I will then post a download link in this threads 1st post for anyone who wants to test it. But a track test event would be good Peter.  ;) ;D

Hawk

Quote from: RiccoChicco on April 14, 2014, 10:37:20 PM
You don't need to create a very high poly track surface, it will be too heavy for the game. You only need to have enough polys in corners where you take a lot of angle. The easier way to know, is to have a "low poly" track surface, and to see where you fall after the first export.


Then, you detach the falling turn, you smooth it (here a turbosmooth should be good, with only 1 iteration to start) and you export the track again. If you still fall increase the turbosoomth iteration 1 by 1.

Don't forget that a high poly zone of a track = FPS decreasing while in the zone. Try to make the track as light as possible, so if you can save some polys, do it  ;D

Sorry Ricco, I have to disagree mate. :)

I've been told on good authority that, when modelling a track surface, it is a mistake to try and optimise the same as you would for normal game objects. The track should be created with uniform evenly spaced quads throughout the whole track surface; this also makes texturing easy and professional looking without any stretching and distortions. Also that the resolution of quads needed depends on the type of track you aim to create, ie: whether the track has a lot of gradient and height changes that could require a higher resolution of quads. Also that because the collision model is often derived from the track mesh model it is very important that the track surface mesh consists of uniform and evenly spaced quads throughout the whole track surface to avoid collision detection problems. :)


RiccoChicco

Well, I use my method to do some of my tracks (TT Mini, Oschersleben, Pau and others) and there isn't any difference in term of texturing.

I don't understand your point of view about "uniform evenly spaced quads throughout the whole track surface". You prefer to have a lot of useless polys?  :o


SA_22

both of your are right.... more in the corners is definitely better and for bumps, inclines etc.. however you can optimize it on the straight flat sections

but to be honest ( not sure about this engine) but tri's are not that expensive for games unless you take the piss.. textures, alphas, dynamic stuff like lights, objects is what hurts.

should be able to keep the texture clean on optimized track as long as you uv it correctly

but without knowing exactly what the collision export is doing its hard to say the best way to go about it... because it's not just exporting the track mesh as is, which i thought it would, atleast for the actual track.  for example take that track in max and throw the pro optimizer on it and crank it up... you'll get some idea of what i believe it is doing

Hawk

April 15, 2014, 10:58:01 PM #12 Last Edit: April 15, 2014, 11:00:37 PM by Hawk_UK
Quote from: RiccoChicco on April 14, 2014, 11:33:53 PM
I don't understand your point of view about "uniform evenly spaced quads throughout the whole track surface". You prefer to have a lot of useless polys?  :o
Sorry Ricco, but they are not useless polys. :)
The track surface collision detection model is often, though not always, taken from the track surface mesh, and if the toplogy is terrible it can lead to problems with the collision detection model taken from that badly modelled track surface mesh; at least this is what I was taught as one of the rules of track surface modelling. I was also taught as a rule that, you don't optimise a track surface model the same as you would for other game characters and objects because it can cause problems with the way the bike or car models can perform on track.

Another good reason for these polys would be that it will allow for the modelling of track surface height differences, undulations and bumps(proper bumps, not grand canyons that we have often seen in converted tracks that cause the bike to crash. Lol) in a track surface.
Put it this way, if you had laser scanned track data for a track surface, would you then strip out all the data representing the height changes, bumps and undulations? Where do you think the modelling of all these undulations and bumps in the track surface come from? They come from ploys.

Most modern PC's with a decent graphics card can well handle the limited sized track surface data required for good detail and topology for a 2 or 3 even 4+ mile racing track..... Even now we are talking about the creation of a 36 mile laser scanned track of the IOM!! Are you still worried about what you consider "useless ploys"? And if it's slow FPS rates you have in mind, then when people rip a track or convert a track from an originally ripped track, they might care to go through all the mesh topology and check all the vertices and edges and make sure they have no "ngones" or "split polys", and also to clean up the mesh topology itself(Ripper software very rarely, if at anytime, extracts a model cleanly), all these modelling errors combined throughout a badly modelled track will greatly slow down the rendering process and definitely effect FPS rates from what could be achieved if these ripped track meshes were cleaned up properly before release. :)

Hope this helps for you to understand better of what and why I'm trying to test this track surface in the way I have modelled it.   :) 8)

If you still think I'm in error, then please explain this from your knowledge, either that or,  we can just agree to disagree for now and let the results of the test speak for themselves. :P ;D 8)


PS: I would be interested to see the source files of the tracks you have created.   Maybe I could learn something? ;)

Hawk

Quote from: SA_22 on April 15, 2014, 12:56:53 AM
both of your are right.... more in the corners is definitely better and for bumps, inclines etc.. however you can optimize it on the straight flat sections

Yes, there are straight sections of tracks, but very rarely if ever flat.  :)

Quote from: SA_22 on April 15, 2014, 12:56:53 AM
should be able to keep the texture clean on optimized track as long as you uv it correctly

This is very true, but I'm sure you will agree that if the mesh is modelled well with good topology, this makes the UV mapping and texturing SO SO much easier.  :)
UV mapping and texturing a badly modelled mesh can be a complete nightmare. Hehe

RiccoChicco

Well, it seems that language make me say things i don't want to  ;D

For tracks (especially tracks for bike), the mesh is very VERY important. The topology needs to be very good in turns. But from what you said I understood that you want to have the same mesh "frequency" all along the track. So I was saying that even if you need to have a good topology all along the track, you don't need to have as many poly on a straight than on a very sharp turn.

Here are some screens, just to be sure that we are saying the same thing. I made just a straight and a curve as sample mesh. Things are a bit exagerated for the explaination  :P



Here's what I understood from what you've said :

Picture 1



Here's what I was talking :

Picture 2



Picture 1.

You can see that the "frequency" of quads is everywhere the same

Picture 2 :

Straight : I think you don't need so many quads on the left part (a straight), because the  bike should'nt be on angle here. That's why I have so few quads here.

Start/End of the curve : the lean angle will not be very important. Let's say 20 degrees. Again, having a lot of quads here isn't necessary. But you need to have more than on the straight, because of course you will start to lean.

Middle of the curve : On this part of the curve, you will be on max lean angle. You need a lot of quads, especially if there is undulations or bumps. That's why there are so many quads here.




Maybe we are talking about the same thing since few days, but we don't understand each other  ;D