Character floating above the terrain at fixed "altitude"; not following terrain (imported static mesh)

Hi everyone. Total noob alert here; please be gentle.

I’ve recontructed part of a golf course with a drone and photogrammetry. The result is a textured FBX static mesh model, which I imported in UE. Goal is to let the golf course manager play with it and to possibly let golfers explore the course before actually going to play.
The idea is pretty simple: 1) use a first person shooter template, 2) import FBX and texture, 3) add trees and bushes (I removed them from the initial point cloud and 3D model in the photogrammetry program, since it’s hard to reconstruct them realistically), 4) compile.
However, my character is floating in the air and not following the static mesh terrain. It seems it’s just walking on this grid thing (see attachment). How can I make it walk on the surface of the mesh?
Thanks people! :slight_smile:

EDIT: already fixed it :slight_smile: Collision settings were wrong.

that will be a very heavy collision mesh if you are using “complex as simple”. There are ways to decimate the mesh (reduce its tri count while keeping its shape) in your 3d editing software of choice. Decimate it, save the lower tri count mesh as a collision mesh and use that as the complex collision.

Not really necessary for a proof of concept, but something to think about if the project gets to an end user stage.
Good Luck, sounds like Its gonna be awesome!

Thanks for your feedback! My golf course static mesh has about 1 million vertices, so it’s not really that big or complex. I did use the complex as simple option for collision. Is that perhaps the reason why my final “game” is 8 GB in size?? That’s ridiculous. I only imported a small piece of the total golf course (5 out of 45 holes) as a static mesh and just added trees along the borders and some bushes scattered across the terrain.

Since the terrain is photo scanned, I’d bet the size is coming from the textures. Really depends on how you go about mapping and baking the texture though.

I’m a blender user so the decimate and multi res tool in that might help out a lot with the size, you can then choose what size resolution the final textures will be and how the UV data is displayed. essentially bake the higher res model and textures to a lower res version of both.

you’ll probably want to do some work with LOD (Limit Of Distance) meshes ( which the decimate tool can also be used for) and break the course into grid sections if the plan is to have an “open world” that is traversable.

Though admittedly, it’s been a while since I’ve used any sort of photo scan/point cloud software. Not sure what the standard approach is these days is to get them into a game engine asset, but breaking them into a grid pattern will ultimately make everything more manageable for sure.

Side tangent here:
There might be a solid case for hand painting a terrain mask too, and treating it like a normal “Unreal terrain” instead of using the actual photo scan textures. That would reduce the file size the most I think.
You could use one 4K texture for each grass type (and sand and such) but over all the course would still have the same geometry. bit more manual work, and it would lose some realism, but it would be much less memory and storage intensive.

I’m no expert with unreal engine, but that is where my mind goes to reduce the size and ram footprint the executable would have. Remember not to optimize too soon though. Keep going on your dev path, and if you run into bottle necks, then maybe try some of these ideas.

Do you think that performance is affected by the complexity of the collision mesh? It runs smooth as silk on my desktop (which admittedly is a beast), but I’ve also tried running it on my laptop… got like 1 or 2 FPS. Horrible. Or are the trees the culprit here? There are like 3-4 thousand of them in total and they all move in the wind, with dynamic shadows. Trying to make this thing work on lesser machines as well :slight_smile:

If there are that many trees, and if they are full models, then yes. Try setting up their LOD so only the ones close to the camera are animating and trying to render in high quality. Transparency (leaves) for systems that don’t have a graphics card, eats up CPU cycles since it can’t do the blending and lighting calculations in parallel. each leaf plane is adding another draw calculation. 30 leaf planes for 4,000 trees being affected by/effecting dynamic lighting. and you got yourself a slowdown on less powerful hardware.

At the risk of zombifying the thread - your edit mentioned you fixed it by changing collision settings - to what? from what?