Terrain/Track & Scene Poly Limits

[AzDesertRat]

Hey folks,

I have read thru the ISI docs, tried using the forum search options and typical Google search but was not able to find any specifics related to my questions so I'm hoping the vets can shine some light. I understand that there are a lot of variables involved so I'm really just looking for guidelines at this point.

1) Terrain (track included) poly count max threshold and recommended range to retain rendering performance
2) Total poly limit for entire scene including objects.

My main reason for requesting this info is that I have access to a large repository of lidar terrain scans, thanks to subcontracted work that I do for the software developer of a leading golf simulator unit. This simulator is currently used as the main club fitting system by many of the top names in the industry (Cobra/Puma, Cleveland Golf, Adams Golf, Fujikura, Taylor Made and PING). Given the stature of the aforementioned clients, the highest level terrain accuracy is an absolute must, which is why we often will use hi-res lidar data (1 foot to 3 foot horizontal spacing with 6cm vertical accuracy). Further more, all data is required to be geo-referenced so the software can provide precise point-to-point distance info.
http://www.foresightsports.com/produ...nce-simulation

Obviously, this kind of data must be filtered for use in a real time rendering engine so I process it thru several different software applications to produce a final terrain mesh (poly threshold is 2 million, ideally try to keep the count around 1.5mil). Initial import of a course plot using 3ft lidar results in about 12 million polys. I use one amazing application to decimate outlying areas or surrounding each of the holes. The filter used is able to smartly retain topology structure by repositioning replacement verts based on some fancy algorithms that measure slope angles, edge concentration, planar continuity and such (all I know is that it works brilliantly, LOL). After this point I then use a hi-level sculpting program to refine details as needed and brush reduce/smooth transition areas. Attached is a sample section from a road course I've been working on recently. I included a couple shots each with an alternate wireframe layer so you can see the poly concentration on the road section. Conforming the splined track object creates great results in Max but just like building a house, if the foundation is screwed up then the rest of the house is going to have issues. For this reason I don't want to delve too far before I get clarification on the poly counts.

RC1a.jpgRC1b.jpgRC1c.jpgRC1d.jpg

Thanks in advance,

Rat

[Simon Peace]

You my dear chap are very fortunate to have access to such datasets. I would dearly love to apply Lidar to the projects I am working on. I would be happy to collaborate on such a venture if it were possible. Do you still have access to the equipment? Are you in the UK? (nah thought not..........) but seriously with realroad, you probably don't want to go too far in resolution of the polys. My track (3 mile) has some 9000+ polys which is 4 wide for 10m track width.

I would be interested in a fully costed equipment and workflow that uses such scanning to produce my tracks from. My customers are also requiring accuracy, but at a cost.. what does the initial scan? plane? or vehicle?
PM me?

[SmokinJo65]

Simon,

From what I have heard in another message that Luc said to Sam Moss that he should probably go 6 poly wide for a 10 meter track. Mine is 6 wide for a 10 meter as well for the main and club track but I used the same 6 poly for my 2 pit lanes which are 7 meter but have some curves in them.

Maybe I might have went a hair overboard on the pit lanes but Luc did say there tracks typically are 1-1.5 meter polys. On some screens shots of tracks I see I see far more polys like 8 across and seem to be tighter then mine even but I have no idea how long there tracks are either and mine is 3.1 miles with a 2.8 mile club track.

Just as an FYI, I have 20,149 polys so far but that includes 2 cloned planes that need to stay there hidden I guess for the vert cutting thing to join my main/club track to the pit lanes freew67 showed me.

Rat is also my good buddy..lol, he got me into this mess I'm in. I'm to bored with golf course designing right now so figured I'd try something else..

[blakboks]

Based on what some of the ISI staff have said, the game engine is very scalable. So, it's mostly limited by hardware. From what I've understood so far; it's mostly limited by the number and types of materials, and from the quantity and size of textures. Obviously, a track with 2GB of textures isn't going to run so well on a video card with 512MB of VRAM. Plus, it's always going to be a balancing act with the number of objects on-screen, their materials, etc.

That being said, it's up to you how you would like to deal with this. You can make your track super detailed for future hardware, but add in lower-resolution geometry for the different visgroups--leaving it up to the player to adjust the quality based on their own setup.

Also, it might help to break up larger objects such as the terrain. I 'think' you can get better performance this way. If you have one terrain object, no matter which direction you look, that object will always be evaluated and drawn. However, if you break it up into smaller objects, the ones that are not in view will not be evaluated or drawn.

I'm also curious if it's efficient or even possible to do LOD's for the track surface itself--breaking it up into 10-20m length patches, and setting only the highest-resolution surfaces with a 0-20m in/out draw distance (and simplified track geometry for >20m). I'm not sure how RealRoad would react to this. You would probably see the groove pop in once the high-resolution geometry comes in. IDK...would be cool if ISI could tweak it to be able to use LOD's (and share the RR textures across all LOD's), that way we can have super high-resolution LIDAR 'quality' geometry without a huge performance hit.

[Luc Van Camp]

These numbers are NOT set in stone and are approximates of what worked for Portugal:

• Road surface: 40.000 tris (or 20.000 quads)
• Entire scene (including TSOs): about 850.000 tris

These are just examples. Monte-Carlo for instance uses a lot more polys (and has more aggressive LODing).

You'll want to optimize the RealRoad surface too, with less polys on the straights and more in places where bumps make a difference (braking zones and in the corners). Here's a quick wireframe shot of Portugal's T2/T4 that explains this visually:
Portugal_Wire.gif

[AzDesertRat]

Thanks to all of you for the excellent responses, very much appreciated.

This particular road course is approximately 5.8 miles in length. Being able to control the mesh levels surrounding the track I was able to keep the track area at full 1m resolution and decimate the remainder enough so that the entire terrain base is around 400k. I believe this is a good starting point for such rugged terrain with quite a bit of elevation changes.


Simon,

Wish I had direct access to the equipment but I'm not that lucky. However, I do receive the datasets in bare earth deliverable format. As an FYI, we've actually used publicly available data for several projects when it can be located. You might be surprised by just how much is currently available at no cost, typically thru county websites. There are 2 states in the US that have complete 2m coverage readily available for public download in .las and .asc formats. Unfortunately, the UK is another story. The region has limited coverage below 5m quality and to access it is very costly. In some cases (Carnoustie, Turnberry) I was forced to reconstruct courses manually via photo references and topo maps for general slope guidelines. That was a long time ago and after using lidar data since then I couldn't imagine ever doing a course that way again, lol.


Luc,

Thanks a lot for listing specific values and example reference to Monte Carlo. I can understand that track would require multiple LOD's per building object, especially with how densely concentrated they are placed around the entire track. However, are you also saying that the track/terrain was split into sections and then different level LOD's created per section?


Rat

[Luc Van Camp]

No, there are no LODs for the terrain in any of the ISI tracks.

[CdnRacer]

@AZ


You are going to become famous my friend!

[SmokinJo65]

@AZ


You are going to become famous my friend!

Please don't give him a complex as I'll have to listen to it every time he is on Teamspeak with me..lol

[Guineapiggy]

Correct me if I'm wrong but wouldn't track/terrain LODs be problematic as the actual 3D model is typically part of the physical interactions? If, say, kerbing were to flatten out in the distance or bumps were to disappear anything not on camera would be driving a different track. Of course it was, (likely still is) possible to make as separate visual and physical track but I doubt that's going to yield much optimization. LODing really only works on non-terrain objects like cars, buildings objects outside the field of play.

[AzDesertRat]

Ok, thanks for clarification on the terrain not using LOD. Coming from golf course design there is actually many similarities to constructing terrain plots for tracks IMO. Like it or not (I see Joe has taken some grief for golf references, of course he does have a unique way with words, LOL) a fully 3D rendered golf simulation is at least if not not more graphic intensive than any other 3D engine sim. This is mainly due to the thousands of detailed 3D foliage that animate in real time based on wind strength/direction (Speedtree in our case, about 15k each) and larger area volume of hi-res terrain (about 1/4th of a typical 1.5 million poly plot). In both cases it's a matter of putting mesh detail where needed (playable region) while optimizing off track/course terrain to achieve the best possible performance balance. The engine used for the golf simulator does actually have a user controllable option for automatic terrain LOD generation based on distance from the player/ball viewpoint. When a shot is played the ball travels in real time and is displayed from a "ball cam" view several hundred feet above the plot at the shot apex for full shots. Without the terrain LOD system this type of view would be a real frame killer and not possible. Even a fly by preview like the one below would stutter like crazy without terrain LOD. Although I'm sure this would be much more difficult to code in a racing simulation due to the vehicle speeds.
http://player.vimeo.com/video/342963...e=0&portrait=0

Enough with the golf reference, I'm just really looking forward to creating some fictional tracks for RF2. I've always enjoyed point to point rally racing and hill climb events so eventually the plan will be to tinker with one of those if ISI adds that race type as a stock choice. For now it's a new learning experience that is a very enjoyable way to spend my free time.


Rat

[blakboks]

Correct me if I'm wrong but wouldn't track/terrain LODs be problematic as the actual 3D model is typically part of the physical interactions? If, say, kerbing were to flatten out in the distance or bumps were to disappear anything not on camera would be driving a different track. Of course it was, (likely still is) possible to make as separate visual and physical track but I doubt that's going to yield much optimization. LODing really only works on non-terrain objects like cars, buildings objects outside the field of play.

I don't think that would matter, since they use the HAT geometry rather than the render geometry for the physical interaction.Based on the 'Rebuild HAT' switch from rF1, I'm guessing that the HAT geometry is constructed based on the first load of a track and is stored and used completely separately from what's rendered. So, if you only give your high-res geometry the HAT=True flag, then it should work.

Like I said before, though...I'm not sure how the racing groove would work with RealRoad. If I had to guess, I'd say that the groove wouldn't actually appear until your high-res geometry came into view. Of course, this could pretty easily be overcame by storing the alpha for the groove and marbles in a texture where each pixel represents one poly or vertex of the simulated surface. Then you could just re-project that on the lower-resolution geometry. (this mapping would probably be done upon export in a separate mapping channel) But that's all just theory, and I'm not a programmer, so I don't know if it would actually work or even if you'd want to do it this way

In the mean time, I might have to at least try a test of a LOD'd track surface.

[blakboks]

Ok, so I did a test with a LOD'd track and compared it to the same track with 'high-resolution' geometry. While there were some graphic bugs (I believe to be associated with EXTREMELY aggressive poly reduction). And the results were highly in favor of LOD'ing.

My test track was a tri-oval whose original mesh was around 8000 triangles and had a density of about 1.5m per poly.

To make the high-resolution mesh, I simply used a tesselation modifier at 2 subdivisions and no tension for a total track size of about 125000 triangles.

To make the LOD's, I broke the track up into about 20m sections. I duplicated the high-poly sections and reduced the geometry to create the low-poly LOD's. For flat areas, I got rid of all internal edges, so that section only consisted of 2 triangles. For curves/elevation changes, I reduced the resolution back to the original mesh density. I set the LOD in/out to 0/20 for the high-poly sections and 20/500 for the low-poly sections.

RESULTS:
Using the original 'standard' mesh, I had an average framerate of: 145.93
Using the high-poly mesh (no LODs), I had an average framerate of: 101.72
Using the LOD method, I had an average framerate of: 145.11

Plusses:

• Since I tagged only the high-poly LOD's as HATTargets, the drive-able mesh retained all of the bumps and detail, but without the framerate loss!

Minuses:

• It will definitely take some time to set up the LOD's properly. As you'll see from a video I recorded, there is definitely a seam where the low-poly meets the high-poly LOD.
• Also, some of the shading 'can' change, though this seems more to be a bug in the high-poly geometry.
• Depending on how aggressive your LOD'ing is, you can see problems with RealRoad. For the areas where I only had one polygon per track section, the groove never appeared in the low-res geometry.
• Finally, rain and a drying seemed to be kind of buggy, I need to do more research into this.

Here is my video of my test. The seams that you see exist because the high-poly and low-poly meshes don't line up perfectly. I added a noise modifier to the high-poly after creating the low-poly.

[K Szczech]

I can share some experiences with rF1, as I have worked with high poly meshes.

Total poly count - rFactor itself had no limit, but scene was limited by video RAM anyway. It depended on textures and other stuff, so with different mods, the same track had different limits. It was good to keep it around one million. I could have more on my computer, but others could have problems running it. With rF2 having much higher minimum requirement's I'd say a few million is possible, because no users will be running it on 256MB GeForce 6 anyway

As for performance - total polygon count doesn't matter as much as the way things are organised in your track.
First of all - if you provide 2 or even 3 different LOD's for every portion of the map, and set proper LODin and LODout - you can have have a lot of detail in your map.

Another important thing is batching. It's a lot faster to render 10 objects with 10k polygons each, than render 10k objects with 10 polygons each.
So let's say you have a village wit 50 houses. Each house is modelled nicely and is a separate object. You could provide 50 low poly versions of these houses and add them to scene, or you could provide one mesh, with all houses in it. Now get all house textures, downscale them and put them all in one texture, so you can have just one material for all these low-poly houses.

The "sweet spot" for optimal rendering performance on modern GPU's is around few thousand polygons (depending on GPU and driver).

• Since I tagged only the high-poly LOD's as HATTargets, the drive-able mesh retained all of the bumps and detail, but without the framerate loss!

Actually, that's the only working way to do it
If you would set both meshes as HAT, then you would be driving on both of them actually - the one that is currently a bit higher would be the one you drive on.

[machine]

A thought came to mind. Try making you LOD's like this.



The start of Lod 2 has it's shape match end of Lod 1. The rest of Lod 2 & 3 is totally flat.

Making end of one LOD and start of another have same number of points, means they can match shape.

[Luc Van Camp]

So let's say you have a village wit 50 houses. Each house is modelled nicely and is a separate object. You could provide 50 low poly versions of these houses and add them to scene, or you could provide one mesh, with all houses in it. Now get all house textures, downscale them and put them all in one texture, so you can have just one material for all these low-poly houses.

Now there's a passage worth repeating . Material count and optimizing it should always be on your mind during the track creation progress. At the same time, don't just assign an alpha reflect shader to EVERYTHING to keep the material count low. For example, if you have a highly reflective structure with one solid panel (quad), and you're using a dedicated texture, then it is advisable to assign the same material and edit out the reflectiveness in the alpha channel. If, on the other hand, the reflective part covers half of the structure, then it's a good idea to split the object into two materials.

[feels3]

I
If you would set both meshes as HAT, then you would be driving on both of them actually - the one that is currently a bit higher would be the one you drive on.

What if I set only high poly mesh as HAT and as no render and the second one low poly mesh as visible?

I have to test it

[Johannes Rojola]

What if I set only high poly mesh as HAT and as no render and the second one low poly mesh as visible?

I have to test it

Do that, it is interesting test

[Scott Juliano]

I might add that it's probably (and I'm willing to bet on this ) not the track LOD's that increased the FPS, but simply breaking up the track surface that did it. With such high polygon tracks having a single track surface is BAD. The reason is that the parts that you're not seeing out of viewing frustum can't be easily culled out. I've seen increases of 60 FPS simply by chopping the track surface up into several smaller sections (it's also more efficient for the collision system). I normally keep mine to maybe 3K to 4K polys or so (or less if the track is laid out in such a way that it would easily hide sections [like the back straight from the main straight at Malaysia, and even those are broken up more]).

Typically, any high poly, large object, should be broken up to increase culling performance...

In general though, track LOD's are just going to add to the overall size of the RealRoad Database and probably hurt performance in the long run over what they might save you in a few FPS. And, the actual visual RealRoad elements (groove, dryline, marbles) would get confused I'd think...

A better test would have been to have 1 track surface and see what the FPS was. Then break that up into smaller sections and see what your FPS was (would have been an increase I have no doubt), and then make your LOD's and try again. The LOD's PROBABLY didn't make as much of an impact as you may think they have....

As Luc commented on, material count is HUGE--probably more important than poly count. In all cases you should try to atlas textures and use as few materials as possible. If you have buildings that all use the same type of material, instead of 4 1024 textures (thus needing 4 materials), pack them into 1 2048 (called "texture atlasing") and make one material.

[Scott Juliano]

Also, I'll add since I'm apparently in a chatty mood, the higher density tracks are actually a plus because of the surface fidelity you can give them. Small undulations, bumps, ripples in braking zones--it all makes the drive feel that much better and believable...