Terrain/Track & Scene Poly Limits

It's not that easy

Look at your LOD 2 mesh - it has dense polygons on the right side. Byt why? Did 3D artist knew, at design time, where player will be looking at this mesh from?

If player would stand on the left side now, then it's the left mesh that has to be the highest LOD and right mesh can be the lowest LOD. All the meshes have dense polygons on their right side, so if we look at them from the other side, we would basically increase gaps in geometry even more.


A solution to this problem would be a bit different. Look at that:



Note that gap is only visible if Vertex "X" of higher detail mesh is below "Edge Y" of low-poly mesh.
The solution is to lower that edge in low-poly mesh to the level of "Vertex X".

Actually, you should put it just a bit below Vertex X, because you can never be sure that GPU will render this vertex perfectly at this edge.

To save yourself some work, you could just basically lower all lower LOD ground plane meshes a little - not just edges.

Actually that's even easier to do, than providing extra polygons at edges

 

With tracks and when talking about the track surface, we can be quite certain which way the player is looking for 99% of the time.

 

So, I just did a test as you suggested. Basically, I just kept all of the HP geometry and set their LOD Out to 500, and completely removed the LP geometry from the .scn file. There are 22 track objects with the number of triangles per object ranging from 960 to 14720, and an average of 5673 triangles per object.

This time I got an Avg. Framerate of 122.87. So, yes, there is some advantage to splitting up the track to smaller pieces, but it still is not matching the framerate of using the LOD's.

Yes, I partially agree with the RealRoad stuff. In my test, the groove seemed to work ok, but when I manually turned Wet Track 'on' and then 'off', it seemed to dry strangely. While it is possible that it could have been due to the angle of the sun and its intensity on the track surface, it didn't seem to act in that manner. I'm sure that some tweaking to RealRoad 'could' get around these issues and make LOD'ing work better, but I understand if that's not something ISI wants to look into anytime soon.

Very true. I just wanted to do some tests to see how track polycount alone could affect FPS. When I initiated the test, I didn't even expect to see a significant difference--especially on such a small track. I've tried to keep my tests as scientific as possible, changing as few variables at a time as possible.

Yeah, you've got the right idea there. I just didn't do it with my quick and dirty little test.

However, your diagram is a little wrong, you left out some edges. I've corrected it for you on the top image. The bottom one is how I would recommend laying out the edges--you can see the improved poly counts.


While yours would certainly work, here's what I'd probably do, myself: You can notice that the edges are spaced more evenly, and the reduction isn't quite so aggressive. Plus, the last LOD matches with both the previous LOD and itself--this is important, otherwise, you'll always have a seam at some point.

View attachment 895 View attachment 897

 

Yes, he's looking both ways Unless you don't care about gaps he's going to see in his mirrors

Additionally, you should also take trackside cameras and watching replays into account.
Note that solution you're discussing removes gaps when looking from one side, but when looking from other side it actually makes gaps even bigger.

Besides - with extra polygons on edge, you actually create gaps in situation when two segments of the road displayed one after another are at the same LOD, because they are designed to match higher LOD, not the same LOD. A paradox, then

 

i'm new to moddeling, so basically i have no idea about this. however as i read this thread, something came to my mind:
View attachment 1321
Only decrease your polycount parallel to the line of sight. by doing this, all LOD surfaces would allign propperly. and this even makes more sense, since you look at the low LOD surface from a much slighter angle, than you do on the high LOD surface.
wouldn't this work?

 

I can post some shots from Fuji later where I had the same issue but until then:

I found that it is sufficient to increase the lateral resolution, i.e. giving more polys across the track, from left to right. Increasing poly count/resolution along the direction of travel didn't really help those "blocky" parts at all and are graphically unnecessary if your corners were already smooth to the eye. I've also had that issue with the racing groove if enough AI drove their perfect lines, not just with the drying line in the rain.
What's your poly count for the RaceSurface bits so far?

Your wet reflections look great btw.

 

For Fuji I have 31k polys (mostly quads) for the main race surface, i.e. everything you would drive on and where I need/want the racing groove/drying line on.
Counting everything I want wet weather reflections on that increases to 37k polys due to the huge amount of tarmac runoffs at the track.

8 is probabaly enough for narrow tracks. The front stretch at Fuji is 22m wide which then means ~2.8m poly width at 8 segments. I probably won't be re-doing the race surface for the track but I wish I had gone with more polys across the track as that's where the "blockiness" of the race groove/drying line are most apparent. Increasing the lateral resolution from say 8 to 12 polys is the quickest way (for us at least) to reduce that blockiness a bit.

Something else I tried was manually cutting the mesh to add vertices at the edge of where the racing line would be, to increase poly/vertex count only there:
View attachment 3179
It helps some but frankly I wasn't happy enough with it to also do it for Topeka or any of the other tracks we're working on. If there's only a single place on your track that might be a way to lessen the blockiness only there though.

Increased poly count on the racesurface meshes also allow for a more accurate racing groove to form - more vertices equals more points of differing grip levels. But that's just a nice side-effect.


As far as performance goes - avoid LODing the RaceSurface instances. I tried that with Fuji and it was awful, it actually cost performance and created stutters. On my system I barely noticed it (but it existed) but for argo0 who helped me track this issue down it made the track undrivable. I suspect that wasn't related to poly count but memory or CPU bandwidth, moving the objects in and out of some RAM or other.
And cut them up into a lot of smaller pieces. I'm guessing at how rF2 works but I suspect it dynamically creates what used to be a static HAT surface which is what you'll actually drive on - the bigger the pieces are it has to load for that, the slower it will be. For Fuji I have roughly 40 main RaceSurface segments, plus all the runoffs and pitlane segments that likewise should not be too large.


In a perfect world I wish rF2 would interpolate the edges of the racing groove/drying line across a quad or more specifically across the diagonal edge of that block we see. I think that would greatly enhance the look of the groove and drying line.
Also, a RealRoad material without the groove/drying line layer to save a bit on CPU for those runoff areas that need to reflect when wet but don't ever need a groove on them.

Here's a quick mockup of such interpolation - all I did was color in exactly half of the two blocky segments.
View attachment 3178

 

Have you tried flipping the triangulation? It probably won't completely remedy the problem, but it may help it look a bit better. I'm not at my home computer or else I'd try it, myself.

 

The reflection option about "draw distance" is the one under the Instance tab and can be set for each object? I was going to test this out in a few days but I suspected it might not be enabled.
I think you can control the reflection limits on the global level with the StaticSwitch line under ReflectionMapper=REFLECTEDENV in the .scn. If you increase that the reflections should go on for further. I haven't tested that yet either though.