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

[Hawk]

Thanks janaucarre.... This is only a test for the track surface mesh to see if we can find the best way to model/remodel the track surface meshes for circuits in GP Bikes.

There is no best way it take many technics to mke a track work, Game physic suck in some areas,   surface mesh shoudnt be as one the game will read the whole circuit at the same time not good for FPS. to get some corners to work they can't be 100% accurate to real life in some case's.   I have 21 versions of seprang model while I was fixin the corners new model for every fix I done and exported and merge cnterline drop it in the track folder, Barcalona was a killer I wonted to give up many times.


The game finds bumps where there should be none it a nightmare

@ RBp: I stand corrected..... Your right to a great degree in that there is "no one" best way to model a track surface; as you say, we all have different techniques when it comes to modelling 3d objects. 

However, as for your opinion that by creating/separating a track surface into several separate objects generates better FPS rates, well that is very questionable. In game terrain/object distance rendering has, as far as I understand, got nothing to do with whether in game models are separate/ed or not; however, again, as far as I understand things, the CPU/GPU task time is greatly increased if they have to render objects(ie, a track surface) if it is split up into several separate objects? This is how I've understood my studies on the subject of 3D game rendering; maybe someone who fully understands this subject can enlighten us. 

When I look at some of the tracks models, I honestly think it is easier and best to just totally remodel the track surface instead of trying to smooth out the current bumpy surfaces as from my experience the smoothing tools often leave subtle uneven poly's that still generate slight ripples in the track surfaces(especially noticeable on very slow hairpin type bends), but if you totally remodel the track surface then the surface comes out very smooth.
But yes I also agree that it doesn't help when there is also a problem with the bike physics that still need tweaking to sort the problems of uphill/downhill cambers and the effect on the handling of the bike. But then again, is it the bike physics, or is it to do with the virtual rider and how it intervenes in certain situations? At this time we just don't know for sure. It is very frustrating at times.  We hope Piboso can sort this issue out for the next release.

I pretty much finished Croft and Brands, was starting on thruxton (shocking bumpy) but might look into this track so I can I help you out with ideas on how to fix corners, think I know how to make that corner work but need to test it first myself.

Brilliant! Two more great british circuits.... Nice one(or two) mate! 

Would be good to bump ideas off each other.... My big problem at the moment is from my posts above about exporter problems. Thought I'd got the procedure down well, but for some reason it won't export my new hairpin section of track that I rebuilt at higher ploy density? I've read the FBX-EDF exporter has issues with certain things(waiting for Piboso's fix/update), but I will try it to see if it will solve my problem. 

[RBp]

I  replace the track model with bumps for a new model that the way I smoothed all the other tracks, it not needed around the whole circuit like you have done, that just a waste of time really, it's not wrong but a much more time consuming way to fix tracks.  it not possible to smooth out bumps with just modifiers the track section has to be replaced. Sometimes even that not enough to make a corner smooth and you need to then use a smoothing tool,

Im not on about rendering,  it the calculation on collsion surface, it take a lot longer to calculate a large model than a smaller one, I think that why evey track is made from section instead of one piece.  Every track is made like this so I would say that the correct way to make a track surface but I could be wrong.


What I do know is that the physic make track making really hard.

[Hawk]

Hi guys.

Just wondering how long the FBX Exporter takes to generate a .map file? It says the log has started twice, and I've been waiting now for must be 15 mins and still no .map file generated in the Mallory park folder?

Anyone got an idea of how long it takes, as the EDF max plugin exporter didn't take this long.... Wondering if the FBX Exporter has crashed?

UPDATE: I posted this @ 10:46am, it's now 13:00pm and I'm still waiting for the FBX Exporter to finish exporting my .map file...... Good job I was able to do this while working, and yeah... I think it must've crashed guys. Just thought I'd give it a good chance(Truth is I totally forgot it was still running). LOL 

UPDATE_2 @14:00hrs 21st April 2014:  Ref: I'm using FBX2EDF Exporter version 1.0 - Ran it straight from file, loaded my .fbx track file, saved it to my Mallory Park track folder, pressed the okay button. The log started in the black app window, then I wait for the finished log message to appear and the "Mallory Park.map" file to appear in the Mallory Park folder, but nothing happens even after a long wait? Any ideas? Am I doing something wrong?

[Hawk]

Im not on about rendering,  it the calculation on collsion surface, it take a lot longer to calculate a large model than a smaller one, I think that why every track is made from section instead of one piece.  Every track is made like this so I would say that the correct way to make a track surface but I could be wrong.

Collision Detection: As far as I understand, the major work of calculating the surface collision detection is done already with the creation of the .trp collision data file, other calculations needed(as the bike moves through virtual space) to detect surface collisions from that .trp data file should be a walk in the park for modern PC's. The collision detection calculations are done per poly face the object being detected is intersecting, but only for poly faces that an object has intersected(Greatly cutting down the need to calculate for each and every poly face in the in game 3D models?) Again, I could be wrong, but this is how I basically understand the procedure? The collision detection optimisation algorithms in place these days don't require the whole scene to be calculated each time their is any movement in virtual space. This is why I wonder why you think that it is better to split a single object into many separate objects to achieve quicker collision detection calculation times and therefore you presume better FPS rates? I hope I've understood you correctly? 

Track Surface Modelling: Personally, and this is just my preference really, I find rebuilding the whole track surface a lot easier and quicker than messing about cutting and rebuilding parts of a track, especially if the track is ripped and the poly's are in tri's and not quads(no one works in tri's if they can help it). Also if I have built the whole track myself then I have the curves control points locked in place to be able to easily adjust the surface anywhere on track to alter or improve the run of the corners/track widths/cambers/undulations or inclines, etc, etc without any distortion in the topology of the surface poly's. I just think it's a better workflow and makes UV mapping/texturing SO much easier.
But as I say, this is just my preference, and as you rightly said RBp, we all have our own ways and techniques of doing things. This is one of the things that makes this field of work so fascinating, the fact that you can discover new techniques from others that fit into your way of doing things, and also could save a lot of time and work in the process.
My way of thinking about a project isn't to particularly find the quickest way to achieve one particular stage of development, or to save time, but to look at the project as a whole, because what may seem to save you a lot of time now, may well later on in the project cost you a lot more time to finish another stage later. Also making sure that if you had to come back and make alterations or updates, that the techniques you used in your earlier work will have made it so much easier to achieve those updates or alterations later.

I hope I understood you correctly with regards to your thinking on the collision model detection calculation process? 

[RBp]

Im not really certain myself on collsion stuff, I did ask Whitham about joining all the grass models togeather when I started and he said that a No No as it cause FPS issue, Grass on nordschliefe had to be made into little models to give good FPS.

Track surface is a strange one due to how the game physic work,  I can normally get away with replacing the affending corner and replacing with a new plain but there times this wont work, 

Mallory park harpin is a good exsample. your track should work fine but as you know it still crash's the bike everytime for pretty much no reason that I can see or explain, you said yourself there no bumps on the model the topology is good, putting more poly's on the harpin don't have the desired effect in game which is annoying. In this instance I started to remove the polys and have just 2 polys for the whole corner, A 1x1 plain and rebuild the surrounding model around this new square track model.

Im sure this is not the best way to model nor is it 100%  realistic to the real life track but the game engine suck's and at time's it seems the only way to make the tracks playable, Here a WIP of this fix on Mallory harpin. the bike don't crash at all now, surrounding models need a lot of work still.

I wont post the .max file as people will laugh at the fix. let me know if you wont the .max file to look at.


http://www.mediafire.com/download/77z7oxq22a9v2fz/Mallory+park.rar

[Hawk]

@RBp: Thanks for that RBP. 
The new section of hairpin you put in their certainly works, it's smooth, and no falls, but like you said, you have had to sacrifice the real layout of the hairpin to get the result, ie: the camber has gone and the track section is now flat. I guess this sort of proves that it is likely or partly a problem with bike physics and cambers, uphill and downhill gradients that needs tweaking on the physics somehow? But then again it could still be partly a collision detection problem too? I really don't know. That does your head in doesn't it thinking of all the possibilities. Lol
In my opinion we shouldn't sacrifice a real life layout of a track, we should work to solve the problem, even if it means waiting till Piboso has got things sorted. Otherwise were going to have a hat-ful of tracks that need updating yet again when the time comes.
But all credit to you for finding a workaround but I honestly don't think it's the answer.... We need to find a solution that will enable us to keep the track layout life like and yet have that hairpin section sorted so riders feel confident to heal over their bikes there with no problems.

I have an update I think will work or work hugely better than my present test track, but I cannot get the exporter to recognise the new section of hairpin track I replaced. I'm working on it. but if I can't get it to export, will you take a look at it for me and see if you can get it to export?

How do you get the lap timings to work properly and record the times? I've got the sector times working but nothing else. Lol
What is it in TrackED that allows lap timings to work apart from the sector markers(as I've already placed those around the track). Is there supposed to be a sector marker at the start and finish line to indicate an end of lap or something?

[Hawk]

@RBp: I also considered joining the terrain together for Mallory Park into one object for the outer terrain and one for inner terrain, but the original mesh is such a mess with split verts and double faces and edges that I decided to give it a miss as I only wanted to test a new track surface nothing else.
But what I mean, is that with the mesh in such a mess I'm sure this would hamper the FPS rates anyway. it would ideally need sorting out if this track is to be published.

[RBp]

I tend to look at it from a different angle,  These tracks have had problem since the alpha I've been told. that coming on for 4-5 years now, I could only see 3 options,

1) make only flat tracks          there are no flat tracks         
2) leave all tracks until a physic fix by piboso        He don't seem to know how after many updates
3) mod the track to work with what we have.        not the best but makes the game/track playable



The timing lines need to be on a colliable object with all the holes on the edge this could be an issue? the startline and sectorlines need to across the track check you got - and + the right way round for the lines

I run 3dmax 09  I can't load max files from newer version, not sure if I can import a scene,  a 3ds will merge all the models and that would need a whole new start.


Don't think this small model will cause to many issue for FPS, I'll find out once I start work proper on it

[Hawk]

Saved Centerline file before merged?: With reference to my export problems since updating and rebuilding the hairpin section of Mallory Park, I'm wondering if the centreline file I built for my first track surface rebuild is somehow connected to the first rebuilt track surface poly's even though it's a saved centreline file before merged; so maybe I cannot use that file again if I alter or rebuild a section of track afterwards??
But then again, the new section of track doesn't show up when I load the .trp file into TrackED, so even if I was to build a new centreline what would be the point if there isn't the new section of track to merge it to? I'm just thinking out loud here for some answers.

[RBp]

Saved Centerline file before merged?: With reference to my export problems since updating and rebuilding the hairpin section of Mallory Park, I'm wondering if the centreline file I built for my first track surface rebuild is somehow connected to the first rebuilt track surface poly's even though it's a saved centreline file before merged; so maybe I cannot use that file again if I alter or rebuild a section of track afterwards??
But then again, the new section of track doesn't show up when I load the .trp file into TrackED, so even if I was to build a new centreline what would be the point if there isn't the new section of track to merge it to? I'm just thinking out loud here for some answers.

Could be a texture problem, some texture don't show in tracked or game, I've converted brands hatch 2005 from GTR2 and texture for the grass edge never showed in tracked or game. mugello one track piece never showed a shadow even thou it was the same texture a the rest of the track,  double check the spelling  TRKASPH_01  or try TRKCASPH_01

export the trp only
load centreline
merge centreline
save trp
put infolder

now see if the bike falls though the gap

.map file take time to export I don't bother with these when fixing the track surface, I just export the TRP and see ifthe 125 crash still after the fix

[Hawk]

I tend to look at it from a different angle,  These tracks have had problem since the alpha I've been told. that coming on for 4-5 years now, I could only see 3 options,

1) make only flat tracks          there are no flat tracks         
2) leave all tracks until a physic fix by piboso        He don't seem to know how after many updates
3) mod the track to work with what we have.        not the best but makes the game/track playable

I understand what your saying above, and the frustrations we are up against until things are fixed, but personally, I think, if we're going to have real track layouts, then it's best to do the best we can with what we've got until the fix is implemented, rather than distort the real layouts for a temp fix. 
The other option is as you say, which is a great idea at this time, which is to just build some flat or at least flatish type of fantasy tracks until the fix is implemented. 

I run 3dmax 09  I can't load max files from newer version, not sure if I can import a scene,  a 3ds will merge all the models and that would need a whole new start.

I use Maya 2011 to model and 3ds Max 2010 to export, so I could export in .fbx then you can import if it's in ,fbx format, yes? It's the best format for exporting to other 3D applications there is. 

[Hawk]

Could be a texture problem, some texture don't show in tracked or game, I've converted brands hatch 2005 from GTR2 and texture for the grass edge never showed in tracked or game. mugello one track piece never showed a shadow even thou it was the same texture a the rest of the track,  double check the spelling  TRKASPH_01  or try TRKCASPH_01

export the trp only
load centreline
merge centreline
save trp
put infolder

now see if the bike falls though the gap

.map file take time to export I don't bother with these when fixing the track surface, I just export the TRP and see ifthe 125 crash still after the fix

I'm ahead of you there.... I already tested that and yes it does fall through the wapping great hole were the hairpin track surface should be. It was quite funny! Hehe

Not tried the alternative TRKCASH prefix though. I'll give that a try.

Thanks RBP. 

[RBp]

this might sound dumb but I got to ask,  you have added the new harpin to the old track model and not got two trp exports?


There one good thing, at least were not MX guys trying to make burms (SP) work in game,   

[Hawk]

The timing lines need to be on a colliable object with all the holes on the edge this could be an issue? the startline and sectorlines need to across the track check you got - and + the right way round for the lines

I don't think there are many places on my test version that have holes in the track side; I did go around the track sealing 99% of them up, so I don't think the timing lines over track holes would be the problem unless I've been unlucky enough to find maybe one of the few that still exist(That would just be my luck). LOL
I've got the lines the right way as far as the left/right -/+ values are concerned, so that isn't the problem. 

I wish there was a proper tutorial.... This shouldn't be this difficult! It's a bit like someone building a plane and then telling a non pilot to just get in and fly and hope he doesn't crash! Crazy, Crazy!. Lol. Thank god for good Samaritans on the forum, like yourself, RBp. 

[Hawk]

this might sound dumb but I got to ask,  you have added the new harpin to the old track model and not got two trp exports?


There one good thing, at least were not MX guys trying to make burms (SP) work in game,

Don't worry... I understand what your saying there. Lol.
Sometimes we all do the dumbest things that we wouldn't dream of looking for when debugging things. Been there done that myself in the past. LOL

But it's a very good question to cover; however, in answer to your question, "No", I've already checked for that possibility, just in case I was having a senior moment at the time. Hehe