track segmentation and maximum sizes etc...

I created a straight track for some other testing (FR3.5 take off) and I noticed some interesting issues with track segmentation.

The track is 3000m long and 10m wide. I tried several different "normalisation" lengths for the spline that I lofted from and I also tried various track width segmentations.

My first try was with 1m square segments. It was interesting because initially the car drove smoothly down the track, but after a while (I haven't worked out how far yet) the car started to bounce violently like it was going over cobbles. I eventually came to the conclusion that it might be something to do with a maximum number of surfaces that the physics model is using and the "array of point data" from the object might be having something to do with it??? so I did a detach and produced a number (5 i think) of sections which I then built. The car no longer bounces!

So the question... is my conclusion that a maximum poly count (whilst not stopping the drawing) is affecting the physics???

Cheers
Simon
(i have a replay if it helps and I can send you the model also if you like)

 

It may be a good conclusion. Another good one may be that it's related to length of one road segment. 3000m in one GMT file could be too large.
You may see what happens if you change that 3000m straight line into a circle 3000m long (so diameter would be less than 1000m).

Or just test a rectangle with the same polycount but make it 300x100m instead of 3000x10m

 

I just noticed in the GMT output roll out a numeric edit called "Max list verts:" set at 16384... could this be the maximum before we get strange results and bouncing cars?

 

It's definitely linked to the amount of vertices/polys. I lofted a road for an oval some time ago and had the car oscillating out of control as well. I at first misdiagnosed it (thought the road polys were too small, causing resonance) but I "cured" it by splitting the RoadSurface mesh into several smaller pieces instead of one big one.

 

Sorry for the double post, had to prepare dinner and saw Jka's post only after I finally clicked Post Reply...

It was good practice with rF1 but it's becoming a necessity with the addition of the RealRoad features. Fuji is borderline on performance and a member here helped me test various routes to fps improvements - cutting up the RaceSurface into smaller pieces made by far the biggest difference, I presume by lightening the load on the CPU substantially.

In the current unreleased version that works reasonably well for said member the pieces are between 120 and 250m in length. I was eyeballing it for poly (and thus vertex) count though, not trying to hit definite length markers. In the released version it was around 300-400m per segment.

 

Well, for rendering it wouldn't make very big difference if your road is in one piece or multiple ones. Unless your road surface has like 100k polygons or more. You won't feel much difference in framerate with 50k poly road segment vs 10 road segments with 5k poly each. Cost of rendering other objects in the scene will make the differences in cost of rendering road barely noticeable.

Unless you cut your road into 1000 pieces with 50 polys each - you may loose half of the framerate on that.

But that's just rendering. The other side of the coin is physics. For physics it's best to have scene cut into many small pieces, so the "1000 pieces with 50 polys each" scenario may be more optimal for physics.

So why am I writting this just under ethone's post? Well, it's beta and if road slicing affects physics, then there's certainly some optimisation not implemented yet. Reasonable physics engine would cut big objects into smaller pieces by itself while loading a track. For better performance it's always necessary to ogranize your scene as a tree of small objects, rather than a list of few big objects or long list of small objects.

Once rFactor2 engine will start doing that in some build, it may be that track slicing will no longer affect performance of physics and you're only concerned about performance of graphics.

And that's why you had to optimize Fuji - because rFactor 2 engine didn't optimize it by itself. It should - and surely will in gold version - if not then I'm going to blame ISI for global warming, bacause people will have to buy more powerful hardware than necessary

Engine developers are the guys who know what kind of slicing is optimal for graphics and what kind of slicing is optimal for physics. This is not something that should be left for modders to worry about. Scene exporting tools should optimize the scene during export or game engine should do that while loading. It's in game developer's best interest.

I think it's a bit "sick" situation when game developer must instruct modders how to design their content to run reasonably fast with their software - it's like telling web developers they need to learn assembler. Especially that such optimizations are reasonably simple to implement.

 

Another reason to break up the size is omni lights and gmt's. RF1 and RF2(I believe) have a limit of four omni lights per gmt. You will get strange night lighting effects if you exceed it. A very large gmt would be prone to this.

 

Ah yes, that applies to "geometric" size not poly/vertex count though. I've had to split a 10 poly object (each poly being around 20x80m) into three seperate objects for Fuji for workable night lighting.
Especially if you model pits or garage areas in one gmt that can get you into trouble as there's usually a fair amount of omnis around those areas.

 

Is there any posibility to increase the visibility range of in car camera?
The behind Car Camera has a much bigger Range.
How is the visibility Range of in car camera determined in a rf2 track?
Does a parameter in the scn file affect the Range or the geometry of GMT Files.

Thanks for any usefull help.

Leonardo

 

In the .scn you have the ClipPlanes=(0.50, 2600.00) line under View=MainView. If the latter value is too low you might see objects getting clipped out before you'd want them to get clipped.

The car cameras have their own ClipPlanes values.

 

Thanks for your hint ethone,

I increased the Main view and Rear view to values up to (0.5,5000) with no effect or improovement.
It seems that the track Camera, responsible for the visibility is fixed to a local track xyz positon. F.e. 0,0,0
(I noticed, that incar visibility comes back, if you re driving on the trackroad nearby this fixed position. May be the smaller the sequementation the better the visibility)

There should be another additional parameter in the track files that is adjusting the visibility.
I will post a reply, if i found it.


thanks Leonardo