202 replies to this topic

[Cheapracer]

MECH, on Jul 17 2012 - 11:56 AM, said:

I was thinking of 6 traces, one extra trace for the top where it goes real steep.
I don't think that the centre sections have that much radius that it would cause big bumps crossing the traces And it's a concrete track so shouldn't be that smooth to drive  

But having that much traces means more calculations..

No, do not use more traces.

Either use a single plane or use 2 planes (low and high lanes) with something to clearly distinguish them apart (different colour tarmac) for driver to choose either.

The banking co-ordinates on my Monza 1938 track may be of help to you, the altitudes are 12 meters apart and 3 meters high banking ... also do your banking first and add extra altitudes for other parts of the track later as they will not effect your banking when added automatically being placed in the same plane.

A trick for your tree line is to use 2 walls, rear wall say 15 meters high and the front wall 10 meters high with 1.5 meters separation.
With the front wall texture get rid of say 20% of the lower texture with your invisible colour (you will see the rear texture 2 meters as well as many holes (again invisible colour) throughout the texture.
Then in your .tex file map the rear wall at say 65 meters and the front wall at say 42 meters (note; non divisible numbers), this is from one of my actual files ..


2059 1 1 80.0 1.0 tree10
2059 2 1 55.0 1.0 tree10a

The effect is to have 3 dimensional  leaves hanging out from the main rear treeline and the .tex file offset makes it visually different as the front row constantly misaligns - that's a better effect if both the front and rear tree lines have distinctly jagged skylines with high and low points.

Here is a sample, note a lot of fullness just from 2 rows of trees, note I have a grass line as well at the bottom of the front treeline. On the right hand bend you can see clearly how it's done but a bit ugly there so you need a bush 3do or people underneath etc to disguise it a little at those points.

if you wanted to get real clever you could use 3 or 4 rows for more fullness. The further from the track the better and also overlapping or zig-zagging will help too (see Papy's Mosport for zig-zagging).

All these walls should be standard unk4 163840 to stop polys being created on top, rear and ends of wall to improve fps.

Attached Files

•  tree1.jpg   48.22K   114 downloads
•  tree2.jpg   28.75K   135 downloads
•  Monza38 bank1.jpg   102.06K   105 downloads
•  Monza38 bank2.jpg   101.19K   76 downloads
•  Monza38 bank3.jpg   99.02K   46 downloads
•  Monza38 bank4.jpg   99.67K   33 downloads
•  Monza38 bank5.jpg   93.18K   24 downloads

Edited by Cheapracer, Oct 14 2012 - 01:45 AM.

[Cheapracer]

Gaus, on Sep 12 2012 - 03:50 AM, said:

I got some strange problem with object in my current project.
I made it in max, export to ase and convert to 3do with ase23do as usual. Other much more complicate objects look OK but this simple factory looks like with flipped normals.

Is anybody have solution or can explain me what the problem is it?

Went through all this when was using trk23do? - old days when we made a .gtk, converted it to a .trk and then compiled from the .trk, had enough time to go make a cup of tea while waiting for the track to compile - and I mean a 40 section small track, not Targa (you guys today don't know how easy you got it!). And back then you had to ask Guru personally for a set of build files!

Anyway, my point is you have 2 choices, learn to use trk23DOZ properly (objl or objf function) or do what I used to do when DOF and DOZ didn't exist, make the factory from textured track walls with height rather than a 3do. I mean why wouldn't you, it's only 4 vertical walls with a roof - for that matter you probably don't need the rear wall and maybe even the offside wall anyway.

Also, there's many a 3do you can make with some imagination using the actual track build files and compiler rather than Max, 123do etc or simply edit existing 3do's ...

Edited by Cheapracer, Oct 14 2012 - 01:50 AM.

[Cheapracer]

Just a quick note on the sometimes poorly understood .fb file for new track builders ...

This is the info at the GPLEA site written by Phil ....


400.0 250.0 0.0 0.0
385.0 250.0 0.0 0.0
370.0 250.0 0.0 0.0
355.0 250.0 0.0 0.0
340.0 250.0 0.0 0.0
320.0 250.0 0.0 0.0
280.0 250.0 0.0 0.0
240.0 250.0 0.0 0.0
225.0 250.0 0.0 0.0
210.0 250.0 0.0 0.0
There is one line in the .FB file for every 128feet (39.0144metres) of the track length.  You should include a few extra values at the end.
First Value:  Distance ahead that you can see, in metres.  This is the 'normal' viewing distance
Second Value:  Distance behind that you can see, when driving forwards - i.e. mirror viewing distance
Third Value: Distance ahead that you can see when you're going the wrong way.
Fourth Value: Distance behind that you can see when you're going the wrong way.

... however, I totally disagree with the "every 128 feet" comment and found that the .fb file actualy splits the track into fractions depending on how many lines you have.

If you have 4 lines then it splits the track into 4 x 1/4's, ie; ..


1000.0 20.0 20.0 0.0
100.0 20.0 20.0 0.0
500.0 20.0 20.0 0.0
200.0 20.0 20.0 0.0

The first quarter of the track you will see 1000 meters ahead, the second 1/4 you will see 100 meters ahead, the 3rd 1/4 500 meters ahead and of course the last 1/4 of the track 200 meters ahead* (see below) ..

If you have 10 lines then you have 10 track fractions - a track of 5200 meters will have your .fb lines consecutively bought  into effect every 520 meters of track etc, etc ...

*Note that the draw distance is a bit of a misnomer, if I have a draw distance of just 10 meters for example, it won't have a draw distance of only 10 meters, it's just the next section won't be drawn until the car arrives at a point 10 meters before it, if the section is 300 meters long it will still instantly draw all of the 300 meters.

For evidence of this, try this .fb file ...

500.0 20.0 20.0 0.0
10.0 20.0 20.0 0.0

... to see the effect. Your track will draw a section 500 meters ahead for the first half and then just 10 meters ahead for the second half. BTW, I always wanted to build a real night track with all sections at 5 meters in length, pitch black horizon and a draw distance of say 20 meters so you would be driving like you only can see ahead what's in your headlights.

The .fb file is the most important file for FPS performance so choose wisely and consider what you can do with your horizon to fill in some of those track gaps effectively.

Edited by Cheapracer, Oct 14 2012 - 01:52 AM.

[ginetto]

Mark.  about the FB settings;
when we worked with Nigel Pattinsons for Targa, I was using your same approach but he told me to do a proper number of lines (39.whatever meters..) to avoid errors in display objects and other problems.
That actually did solve many issues that the track had before to use the correct number of entries in FB file.

So I guess that those many lines ( one every 128 feet) in the FB, are actually needed for a less troublesome as possible track.

I usually use just a single line FB while I start working on a track but then, when close to the finish line, I change it to a proper number of lines and then fine tune it using a replay in a windowed mode and FB adjust by Strava so I can change on the fly the values. Pretty quick job.

Ciao!

[Cheapracer]

Ginetto, on Oct 14 2012 - 09:26 AM, said:

That actually did solve many issues that the track had before to use the correct number of entries in FB file.

Thanks for the input, what were the issues?

Speaking of single lines, the bulk of my tracks are just done with single 600.0 400.0 line! - I've never had "issues" but none were as complicated as Targa either.

[ginetto]

Any sort of graphical display issues.
I remember for sure:
Clipping issues at hairpins and with big 3dos crossing the center line;
unk1 changes not working;
others that I forgot now but I remember that  for some of them, I didn't even thought could be related to FB file.

This is for Targa Florio so is very possible that shorter tracks with simpler 3do or layout, don't stress the system to the point to output an error but I would stay safe since is not a big deal to make the file the correct number of lines

Here is an axtract of Nigel answering about FB issues

npattinson, on Feb 09 2007 - 09:25 PM, said:

... I never got right to the bottom of what was happening after about two weeks of debugging, but had a hunch that the fb file had something to do with it. Jim changed it to a line per 39m, and the problem went away.

From memory, the conclusion I came to was that the longitude covered by each fb line was treated as a section. Any section that was at least partially within the draw distances was drawn (in some sense at least). So with only one section, everything will be drawn, since it's partly within the draw distance. For the test track, there were too many objects of some kind (maybe TSOs, maybe textures, I really don't remember) and some array limits got blown. I think Jim may have explicitly added lots of TSOs to stress test it, so perhaps you're not hitting that limit.

It did at least look to me like the performance would be better with normal-sized fb sections. Whether that difference is measurable though I don't know.

Nigel

[Pablo_Fernandez]

So... the 3º and 4º lines of FB could be related to the lateral objects clipping?, maybe add a few meters to this lines may fix the issue?

Another thing, when I use FB adjust of Strava I write FB values to 3DO and export to FB format into the track folder (I assume it replace the previous fb file), but then always the doz- compile fail, I change back to the other fb and then compile normally. What I'm doing wrong?

[Cheapracer]

Pablo_Fernandez, on Oct 15 2012 - 07:56 AM, said:

(I assume it replace the previous fb file)

What I'm doing wrong?

Assuming and not checking at a guess. Are you actually using trk23doz? Far better 3do placement/clipping management, just need a different .tso format layout compared to TRK23dow and a .hsv file added.

(TRK23dow) [ 10]: 3, 2.0, -7.0, 2.0, 0.0, 0.0, 0.0, 1.0 starter

becomes

(TRK23doz)    obj 3 2.0 -7.0 2.0 0.0 0.0 0.0 1.0 starter   (notice no commas between values)

Somewhere above Ginetto offered a sample hsv file, just make sure you have enough lines in the hsv file to match your track sections. I'm new to TRK23doz (I want the shading function) and if I can work it out anyone can.

Thanks for the extra detail Ginetto, makes sense if in fact GPL gathers and draws 39 meter sections at a time as chunked outputs. I have never been big on 3do's prefering creative wall methods so that's why doesn't affect me as much I guess.

[Pablo_Fernandez]

Cheapracer, on Oct 15 2012 - 08:37 AM, said:

Pablo_Fernandez, on Oct 15 2012 - 07:56 AM, said:

(I assume it replace the previous fb file)

What I'm doing wrong?

Assuming and not checking at a guess. Are you actually using trk23doz? Far better 3do placement/clipping management, just need a different .tso format layout compared to TRK23dow and a .hsv file added.

(TRK23dow) [ 10]: 3, 2.0, -7.0, 2.0, 0.0, 0.0, 0.0, 1.0 starter

becomes

(TRK23doz) obj 3 2.0 -7.0 2.0 0.0 0.0 0.0 1.0 starter   (notice no commas between values)

Somewhere above Ginetto offered a sample hsv file, just make sure you have enough lines in the hsv file to match your track sections. I'm new to TRK23doz (I want the shading function) and if I can work it out anyone can.

Thanks for the extra detail Ginetto, makes sense if in fact GPL gathers and draws 39 meter sections at a time as chunked outputs. I have never been big on 3do's prefering creative wall methods so that's why doesn't affect me as much I guess.

I always work with track 23-doz, and have experience changing the hsv and TSO files.
The only problem is that cannot change the fb file from into Strava's FB Adjust

[Cheapracer]

Pablo_Fernandez, on Oct 15 2012 - 09:00 AM, said:

The only problem is that cannot change the fb file from into Strava's FB Adjust

2 options;

Copy Starva's info by hand into your working .fb file.

Do my method, chop the .fb file into say 6 lines and work out your .fb's based on those 6 lines then go with ginetto and equally duplicate those 6 lines until you have a line for every 39 meters - fine tune some of the lines from there, it's not rocket science and fps isn't as critical as it once was.

[rodsquad]

Hi all,

I worked up the section splitting equations again as the original spreadsheet got lost some where.

If you have an equation for a section Ax³+ Bx²+ Cx + D.

But you want to split it at point 'a' (between section start and end), the new equation factors A^' B^' C^' and D^' for the 2nd half are

A^' = A
B^' = 3Aa + B
C^'= 3Aa²+ 2Ba + C
D^'= Aa³ + Ba² + Ca + D


So that

Ax³ + Bx² + Cx + D = A^'(x-a)³ + B^'(x-a)² + C^'(x-a) + D^'

I"ll try to whip up another spreadsheet but I didn't want the equation to get lost again.

[Michkov]

If I have 3 walls with the middle one a different surface type, say asphalt-grass-asphalt. How small in width can I make the grass wall and still get the effect of running on grass in the sim? Assuming the walls are parallel to the centerline.

Also are the grip values for any of the other surface types apart from the first 3 known?

[sergioloro]

Michkov, on Sep 13 2014 - 04:33 AM, said:

If I have 3 walls with the middle one a different surface type, say asphalt-grass-asphalt. How small in width can I make the grass wall and still get the effect of running on grass in the sim? Assuming the walls are parallel to the centerline.

Also are the grip values for any of the other surface types apart from the first 3 known?

for Porto 58 track we used a very thin grass surface (lets says 10/20 mm) to represent train railroads, and it works perfectly.
for my memories type 1 asphalt type 2 concrete type 3 paint type 4 grass type 5 dirt type 6 sand and type 7 mix of grass/sand, not sure about last one.
cheers

sergio loro

[mcmirande]

Train railroads are actually stripes of grass surface!!!?? They are fantastic and a great challenge, especially because best times are braking with the wheels in the middle of them!

[Nicolas]

When I make a track with GTKMaker and load it in GPLtrk, I see after zeroing some longitudinal mismatches in the order of +/-1. I assume because of rounding errors. Is it important to have them all exactly at zero or can we live with these small errors without effect? If they have to be zeroed do I do this now or only when the track is otherwise finished?

Edit: see my next post for a more clear phrasing of my questions.

Edited by Nicolas, Sep 16 2014 - 03:17 AM.