Is performance I'm getting typical?

[jtbo]

I'm curious if my performance is line with others and if I should do something to improve it which I have not understood to do.

When making longer track, more than 30km, I'm finding that BTB is updating each of four panels one by one every time when there is window on top of BTB, screensaver or if I make any change, this can take around 30 seconds which time I must wait.

Now I tested bit of extremes, I did import 1 061 615 meters of GPS data into BTB, wait time is around 7 minutes after each click on those buttons at top row, for example if I would like to change panel length to larger number so that export would work it takes 7 minutes to get there.

I have read people doing 500km or even longer tracks for really fast vehicles, as BTB is not using more than one core, I'm interested to know which kind of hardware is used to get better performance?

My current CPU is Intel core 2 duo E6750 and I have 3GB of ram, system is not supporting more as I'm using WinXP and not going to move into Vista or 7, have seen enough of those resource hogs at work.

I know of setting that causes updates only after I move nodes, but delay is then after moving node, so I have to wait 30 seconds for around 30km track, of course amount of nodes affects this too, but with GPS data there is node for each 15-30 meters (it varies by speed and some random things), so that makes as on average ~1333 nodes for 30km track.

Setting node type from spline to kardinal has sometimes improved performance from my experience.

Or maybe there is something else that should be done to reduce waiting times or is stronger CPU only medicine?

edit: Splitting the track, I have tried this, but can't really see the light in it, there seem not to be difference in performance what I have observed and even hiding nodes seem not to affect actual waiting time of window re-drawing.

 

[Kennett Ylitalo]

You have to remember that BTB scale goes from 1mm to 100km, a feat that is not so common in 3D world.. The larger it is, more stuff needs to be processed. But that bein said, longer and larger takes longer to process than close and small, obviously. BTB is good for about 15km of track, after that, it gets amazingly slow. For 500km, won't believe until i see one.. Going past 100km is, i believe, the limit. Processor update won't do you any good, i got old 3ghz one core and it is as slow as a dual core with BTB. On another note, try making the same scaled meshes in 3DMax, a 14km track with all the glory in it... (seriously, i don't know what it does, anyone have experience with that)

Also did you uncheck the boxes W, O and S (top right corner) ? Try setting from the options the preferred "update timing" style to immediate and possibly update directx and GFX drivers.

On behaviour with windows: BTB is semi always-on-top (some windows are on-top, main is not but behaves like one..) and it causes delays with other softwares. I think it's got something to do with API settings. I always minimize the BTB window before opening new ones, it behaves better.

 

[jtbo]

I have seen those W, O and S, but to be honest, I have had no idea of what they do.

Currently BTB is trying to export track which I suppose it will fail exporting, but you never know without trying.

I have a track that is over 100km, did export fine and managed to even add some surrounding terrain to it, but I don't know if editing would be very good as it is quite slow with my hardware.

Last time I did update GFX drivers, gfx fan stopped working when resuming from suspend and at windowed mode I started getting very poor performance, old hardware that is too good is tried to be killed with new drivers some suspect, more than 6 months and no fix to that, so I'm cautious now

With immediate updating set it is quite difficult to do anything, it is much better with that other mode that does update only after I move node, but I haven't yet tested unchecking those boxes with letters next to them, however I will test that in few hours if BTB has finished exporting by then.

Minimizing and bringing BTB up would be again 7 minutes, so it would be rather inconvenient (actually can't remember if it would be 7min to minimize and 7min to bring it up, might test that too), but I guess that is what happens when trying to make too large track.

Having only 3D view visible did reduce wait time a bit, but I was excepting more as with all default four views I can see how each window is drawn one by one, quite bit time between each other, however with only one view it still takes more than half the time of waiting, so it is not just the window drawing that is done each time some other window goes above BTB or when screensaver activates and BTB redraws views, probably some node calculations is done too at the time, but my understanding of inner working is limited.

It is really incredible piece of software, which is really making possible for me to make some surfaces to drive on, with my skills calling them tracks would be just not right. I like to explore limits and understanding what limits is a good thing so now I don't need to spend more into CPU then :wink:

Also with really long track, to be able to make all surrounding areas, objects, to make it look nice, amount of work would be devastating, so I don't think that BTB really needs to be able to handle such tracks very fast, there probably is not many that can spend so much time working on track like that.

For me these are just roads I have driven, finnish major and some minor roads, which I like to see in rFactor, even it is just a road and bit of green on both sides.

edit: With W, O, S disabled, only top view, Node type set to Kardinal and update type set to Deferred, wait time with 1096km track is about an minute when pushing buttons on top, so it makes bit easier when experimenting with exporting too long tracks, which I like

 

[Raido]

The amount of RAM also plays a part in BTB performance. I have 4 GB in my Mac, and when I use the program in a virtualiser I can see that it takes up nearly all the memory the machine has, about 90 per cent. If I then load a track, RAM is nearly filled up and occasionally it has to swap out to disk, which is MUCH slower. On my old machine I only had 2 GB and that was noticeably slower still.

So the more, the merrier in this case. In XP you should be able to go up to 4 GB at least.

http://forums.techarena.in/windows-xp-support/790392.htm

Myself, I wouldn't want to go back under 4 'Gigs' when using BTB. I'm not making large tracks so more would probably be better. With 6 to 8 GB it'd probably have enough to prevent slowdowns.

 

[jtbo]

Win xp 32 bit, adding extra 1GB would make just wallet lighter, it might add 100-200MB usable ram, but that is all, because of hardware using same address space, that is why 64bit was needed.

Max mem usage I have seen with over 1000km track has been 2.5GB, Mac's virtualization causes memory usage be higher than without it, so sadly adding more mem is not going to help here either.

 

[jtbo]

For 500km, won't believe until i see one.. Going past 100km is, i believe, the limit.

This 500km, I did read from conversation at here:
http://www.racedepartment.com/showthread.php?t=40140&p=869838#post869838

160km seems to come out from BTB to rFactor and seems to be loading too, one has to remember that these are very basic roads without objects etc. that I'm exporting. It is panel length that is holding back exporting indeed, but then again, if one needs to set panel length to 30 meters or beyond, would that be usable any more?

Exporting stops with error in application or similar error message when panel length is too short for length of track, that might be possible to cure by splitting of track if I understood correctly what I did read from before mentioned thread.

With 25 meter long panels, single track, raw GPS data (with some lines of missing altitude data removed) and terrain added to roadsides with automatic terrain feature in BTB, this is 160km of countryside roads for rFactor and should load ok, it really is just test if such long is possible to make. Covers smaller roads from Pieksämäki to Pylkönmäki, not much to drive, but one can test top speed and suspension of car in it if nothing else and it does show that more than 100km is somehow possible, even it might be not practical or useful
http://jtbo.pp.fi/tiedostot/rfactor/160km.zip

 

[R Soul]

You might be able to split up the gps file, depending on the format. If it's a plain text file containing just the coordinates, like a csv file, you could copy the first ten lines to file1, the second ten lines to file2 and so on, then import them into BTB one at a time. If the file is structured like an XML file, you could still split it up, but you'd have to make sure each one had the correct structure.

Splitting up the full track in BTB is possible. Try this with a 20000m open-ended test track:
Make a copy of the original track (using

), and make the copy active. Delete all but the first few nodes, up to around, say, 5000m. That track can be called Part 1. Make another copy of the original track, and make it active. Delete the first few nodes so that it starts where Part 1 finishes. Then delete the nodes from the end, working back until this track is about 5000m. Keep doing that until the short tracks cover the whole of the original, then delete the original.

You should make lots of backups along the way.

 

[jtbo]

Ah, so that is the trick to use then, track surface has been at default, only panel length is that I have changed. With all these tips I have found speed to be quite manageable for node moving purposes.

For GPS data, I have perhaps bit unique method.
I log with TomTom and NMEA logger mod program to it, it writes standard NMEA protocol ASCII files, then I upload that to site http://www.gpsvisualizer.com/ and choose text output, which I then import to Excel, delete not needed columns, switch lat and long, filter and choose those that have empty altitude rows and delete them, then sadly manually try and find duplicates, happens when I stop with car, those rows I delete too, as it is easier in Excel than in BTB, finally I export file as CSV and import into BTB, whole process is really simple and quick to do when used to it, also splitting file is not an issue at all, just cut and paste to new table, I think much easier to do in Excel than in BTB, especially because of speed.

From navigator to drivable track, maybe 10-15 minutes if export is not taking very long and what surprises me is how well BTB imports the data, road is really good.

For terrain, I have found out that it is what to do last, when rest of track is finished and it is sure there will not be adjustment needed, there is speed and there is issues with terrain positioning etc.
So I do terrain when everything on road is ready, if track needs changes it is easier to remove terrain do fixing and add terrain afterwards, surely would be different if terrain would be some of 'real' terrain, but for these my purposes this has been easiest to do and it does provide quite bit of enjoyment for me to be able to 'create' a track like this, I understand that for most such tracks are not much of use.

I have found how shadows are bit of an issue with longer tracks, there might be also more issues, but that seem to be one rather clear one, with this simple tracks HAT issues seem not to surface yet, but I have experienced such too.

Thanks from tips, most useful as now it might be lot easier to position objects and make some turns tighter. Also I have been considering making several shorter 'stages', might give that a test too.

 

[Lee Knight]

Ive previously done a personal experiment with a 220km point-to-point track using 10 meter panel lengths & then 'sectioning them every 2 or so km's & used 5meters for tight corners.
I got my route from GE Maps via URL so it contains less data points to become nodes then most other methods.
Height data was then done in 3D Route Builder & all data was broken down to 6or7 sections while mapping & pieced together in BTB making sure that the 'origin point' was roughly halfway.
I left the road the standard width although I did move the 'control points' 2 & 4, for the surface, out slightly & reshaped the road for a high crown (helps cut down on the need to camber the corners as much....)
I had heard about the 'body shake issue but I drive in 'front bumperbar' position & never notice it unless I go to another view which includes some part of the car...
The terrain is extremely basic & sounds much like your own.
Export took around 10 to 15minutes (2.8Ghz Quad-core, 2Gb RAM XP32-bit)
First load didn't take as long as SOME other tracks I tried & seems to work fine in rF
Good luck with your project & I look forward to maybe one day being allowed to try it!

(PS- If you DO share a large track, packing it's HAT file can be rather helpful for others too :wink: )

 

[jtbo]

Good points there, thank you from those!

I really had forgotten that import feature that it centered imported track, I remember doing importing of two pieces, but probably never did zoom out to actually see the issue. With this information it indeed sounds easier to do splitting in BTB and as with tips from this thread performance is now really good (less than 1 second delay at 160km track), it should be not too big of an issue to modify that.
Reducing amount of control points at road surface made quite nice improvement in performance indeed, I took two away so there is 3 left from 5.

And I thought that small shaking was just mighty V8 trying to get loose :tongue:

I have had issue with HAT file before, for some reason my rFactor likes to re-generate HAT from time to time, for one track it first did not work, but testing with different car mods started work ok, but later rFactor decided that it will re-create HAT and there was no way around of it, of course it did fail creating HAT and only way was to edit the track to make it work at some way, there I believe issue was large single areas as I took one piece of drivable terrain off and it did remove most of the ground from track.

 

[jtbo]

Two points would of course be enough for editing stage, but I was not able to think that well, so made it final already, however with three points performance is more than what I have used to get, so what I don't know, I don't desire

Quite interesting how HAT creating times can be affected by such difference, that makes one just curious, oh why it is so :wink:

Also I notice some trees etc flicker a bit with long track, shadows I mostly keep off so it does not bother me too much, I think reason why I started to keep shadows off was performance related, but they have been off so long that can't really remember why I did that.

 

[Kennett Ylitalo]

That N-S vs W-E is interesting... Could be just a simple optimization that we usually won't notice as we always design our tracks "sideways", because of screen aspect ratio nowadays...Except those who make their track oriented like they are in real-life (because "that's is how it is made IRL"..) and not use the associated options in other files that define the track location (lat/long) and orientation. I did this error in the beginning, now i ususally use SW-NE orientation during building, it just feels so natural to make that movement with mouse (DownLeft to UpRight) but it think i'll start using W-E from now on.

What about HAT filesize? does that also decrease with orientation? Have to test... Would be sweet with multilayout tracks to decrease the largest unique file of every layout iteration.

EDIT: Rebuild time is affected, filesize is the same.. Now to think of it, the size can't change with orientation, it's only data. The rebuild time increase game engine optimization.

 

[Johannes Rojola]

If it is for example 50km circular track, how do you make out if its more lat or more long? I don't get this at all

 

[Johannes Rojola]

Very interesting. Gotta keep that in mind if I make tracks that are not circular. Btw, is that a any real project of your or just a test? Because diggin' it a lot what I can tell from the images...

 

[Johannes Rojola]

That is a section of the Skyline Drive in Virginia USA. I work on it from time to time. Shadows are a severe problem because the ends are so far from the origin. I don’t mind turning shadows off for track objects but driving with other cars without vehicle shadows is disappointing :frown:

I know what you mean. Have you tried the tricks that helped shadow problem in Targa Florio?

 

[jtbo]

How about adding few turns in sake of improving stability and performance? Of course it does change the track, but if we are talking about really long tracks, would few extra turns be so bad thing if with that trick you could keep track close to Origo ?

I'm thinking that track that would not work well or if at all is not good, but same track with few added turns (so that tracks runs left to right to left to right in BTB) is better than no track at all or not well working track.

Or would it be then better to track be several tracks split up to stages?

For me one even not quite accurate track would be something more interesting than short bursts, after all long track is made as it is long, just don't know what kind of opinions other long track makers are about such 'trick'.