Messages

When I load the "Mallory Park.trp" file into track editor and view the wireframe, all the original track surroundings show up in wireframe, but my track surface doesn't although my track surface must be there because the track texture shows? Anyone know what's happening because I'm having big problems trying to figure out this track integration procedure. I've looked at other track .trp files and the track surface in those does show in wireframe view; I must be doing something wrong in the procedure somewhere. GRRRrRrr!! Where's a proper manual when you need one??

Ref: I named the track surface to: TRKASHP_01HK is this okay?

Great video Arvoss!! Very nice indeed! 

[@Ricco:]

@Ricco:
Sorry I've not replied to your post yet, I will reply to you Ricco, I just want to reply in detail to your post and I'm just a little rushed off my feet at the min. 

yeah know the feeling!..

if you hit absolute on the top right you should be able to position the things manually

then its just playing with numbers to get it in the right spot,

just use the icons, markers etc that show up for each part to help with that.

if you get something right like the start line, save it before you move on to the next.... found the race data windows loved to freeze up on me alot!

Thanks SA... Appreciate your help with this.  I'll let you know how I get on.

In my opinion you can scare/minimize modding questions if you take a note how long it takes to do a decent mod, from scratch build model up to the physics end 
In my opinion most of them asking out of personal interst not knowing how long and how much work it is to develop a bike or a bikeset or only a physics mod.

Well said, C21. 

+1 mate. 

already have a ton of work i need to get through before i can get back on personal stuff ( which again i have a ton of projects to finish)... so unfortunately unless you want to pay me lots of ££££ no lol

maybe when i have free time in the future

would need the rig that is being used to skin the mesh too... that should be it...

No probs mate..... I know what's it's like trying to find the time to do these personal projects. Lol

Maybe piboso could publish the rider rig if he reads this.... How about it Piboso? This would be a great help to us modders(Even if you are planning to change rider mesh/rig in future, we could do with something now to work with and test, that would be great!)

make sure the ends of the center line are definitely connected

after you create the center line click i think its merge in the drop down for it.. makes it match the height of the track

then you need to create the race data... all of it i think

that should be it?

Hi SA. Thanks for the quick reply mate. 
How do you create the race data and position it? Sorry, I'm a total Noob when it comes to track model integration. Tried following Piboso's thread about the track editor but it's very vague for someone who knows absolutely nothing about it.

character art is my thing so if you need any help or want me to take a look at anything feel free to hit me up!

Any chance of creating Barry Sheene and Kenny Roberts riders from 1982? I want to include them for the 1982 Yamaha YZR 500cc GP bikes that I'm creating.

Can you do the animation too? If not then I could take the character meshes and animate them. My problem is just finding the time to do these things.

I presume if you created the files required it would just be case of replacing the default rider files with the rider you wanted and altering the bike "Rider Geom" files to accommodate the different positions required for each rider/bike?

Would be Fantastic if you could do that!

Hi Guys..... I need some help getting this into GP Bikes:

I've finished modelling the track surface and exported the Mallory Park.map/.trp files from 3ds Max.

I copied the Original "Mallory Park" track folder and deleted the original .map and .trp files and replaced them with my exported ones.

I've loaded the Mallory Park.trp file into track editor and created/merged the track surface centreline and again saved the Mallory Park.trp file.

I then ran GP Bikes and tried to load the track, but GP Bikes keeps crashing and won't load it??? Any ideas guys???

I haven't generated a bestline(Didn't think it was mandatory to do so), and I haven't generated the "race data"(start line/grid or pit exit/entrance, simply because I haven't got a clue of the procedure to know how to place them(Again I didn't think it was a requirement just to test the track out); again I need some advice(How to's) here please guys.

If there is anything else I need to know before trying test the track in GP Bikes, I would be very grateful if someone would let me know. Either PM me or post here... Thanks guys. 

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. 

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

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? 

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.   

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.


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

It's a good idea Klax..... There should be some sort of visual representation of the bike for any changes made to the setup to give people a better visual and better understanding to what the changes are doing. Some people get a better feeling for learning setups from a visual point of view rather than just numbers and then hoping they can feel the difference on track, but not really understanding what they did correct to make that difference in handling they may get on track.

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 

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.

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.

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. 

[@Max/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!

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.