• Dear visitors,

    The email issue has been finally solved.
    Thank you for your patience and happy browsing.

    Team ACM.

How to best include large visible (non-driveable) terrain sectors

decnet100

New Member
Hi, here's my first question which I figure someone might give me a definitive answer on, after having played around with blender and the KS editor for a few days. The problem I'm facing is that the track I want to recreate (Innsbruck airport) has loads of terrain visibility as it's surrounded by mountains and you can basically look down the valley and clearly see peaks up to 50km away. A quick calculation using gdal.viewshed looks like this (bright=visible) - and this is not complete either, there are a couple peaks missing to the very distant west which I'd definitely want to include as they're most definitely visible and characteristic):
upload_2024-2-7_17-10-21.png

So obviously, what I'd like to do is to get a good representation of close-ish, medium and distant terrain - I certainly don't need the same level of detail within all these regions. What I did so far was to import a terrain elevation model + orthophoto using blendergis plugin, cut away the parts that are clearly, definitely not visible from anywhere around the track, separate the rest into like 12 pieces (smallest where close to the track), and decimate them all individually to get below 65k vertices - as I heard (and got told by KS editor through crashing when importing too large objects) that that is the maximum size for an individual object. Is that correct and actually set in stone, or are there ways to include larger objects as long as they are set to non-interactive in some way? This works so far, but of course makes it all a bit cumbersome to modify, every change in density from decimating results in gaps between the individual pieces and so on. Also, it seems like I have far away mountains popping in- and out of view when moving the camera around (as in, rotate the car at 5km/h and the background mountain at like 30km distance changes) - I guess that is also dependant on render distance, so if a user has less distance set, they'll have the same problem with other mountains much closer..? After all, I'd like to have a good idea of how to represent the terrain before moving on to adding trees there...

At any rate, any suggestions are welcome - what would be a better process for this, or is this approach of "split up into dozens of <65k vertex objects" basically how it needs to be done?
 
Last edited:

Johnr777

Moderator
The 65K limit is set in stone, you need more, you chop the mesh into more objects.

Theres a trick in CSP to set the far terrain to not have render limitations:

Code:
[INCLUDE]
INCLUDE = common\materials_track.ini

[Material_DistantGeometry]
Materials=
 

Rob Pawn

Active Member
Theres a trick in CSP to set the far terrain to not have render limitations:

Code:
[INCLUDE]
INCLUDE = common\materials_track.ini

[Material_DistantGeometry]
Materials=
does this even help on lower poly count objects in the distance to save a lot of performance, iam curious?
 
Top