[Videos] 's Victory Landscape Collision Plugin

Dear Community,

I’ve been having problems with my landscape collision ever since Physx3.3 was introduced sometime during the Beta.

I have been struggling with the issue ever since because I cannot release my game until this issue is resolved!

**Newer projects and newer landscapes may never encounter this issue!

I was unable to reproduce the collision issue on a new project that was also a third person c++ template project.

But if you are like me and you have landscape collision issues with your existing project / landscape assets…


I have just finished testing my Victory Landscape Collision Plugin!

And it is available to you for your enjoyment!

**Landscape Collision is Fixed!**

I now have perfect landscape collision with the help of my plugin!

**The plugin has two options**

1. Replace all landscape collision

2. Only add triangles of collision to "patch" steeply sloped parts of the landscape, which is where the Physx3.3 collision issues arise.

**You can control all aspects of the feature!**

1. timer tick rates, to reduce any FPS lag for very large landscapes

2. What amount of slope qualifies for needing supplemental collision, if only patching and not replacing all landscape collision

3. Can be applied to multiple landscapes!

How It Works

I generate a dynamic mesh with no scene proxy, just physx collision data after retrieving the landscape vertex data.

I generate the triangles myself from the raw landscape vertex data.

If replacing all landscape collision, all triangles are always created, and regular landscape actor’s collision should be turned off to conserve resources.

If only patching sloped parts of the landscape, you can determine what qualifies as sufficiently sloped to warrant adding the additional triangles


Performance is unchanged, after initial loading. :)

There's a bit of an initial drag on the FPS when the initial setup is done, but if you do this at Begin Play time with fast timers (0.01) you wont notice, it just looks like normal loading time.

For very very large landscapes a slower timer (0.1 or 0.333) might be better for the triangles and components.

You can completely customize how the loading is done.

You can choose to do it all at once and have it be part of the normal loading delay.

Or you can spread it out if you don't need the collision immediately.

This plugin has saved my project, I can now continue building more of the landscapes for my game and enjoy running around on them!

Entire C++ Source Code

The entire C++ source code is in the plugin!



I have 2 videos to share!

**Video 2 ~ Victory!!!**

See next post for video of my Navmesh-free AI jumping around on the steepest slopes of my landscape!


**Video 1**

**Replacing Sloped Parts of Landscape Only**

The red triangles are only in this development build, not the final version :)

I needed to visualize the collision triangles to make sure I was building them correctly :)


Download (5.87MB)

Direct Download Link from UE4 Wiki

Indirect Wiki Download Link


1. drag the plugin to a folder named exactly "Plugins" in your project main directory where the .uproject is located.

2. open editor, go to window->plugins

3. check to enable my plugin

4. restart the editor

5. click on a landscape

6. go to level blueprint

7. right click and add the reference to your clicked landscape

8. right click and search for victory landscape

9. connect the landscape to my node 

10. add the event begin play

11. Celebrate!

**Picture of Final BP Setup**



Some pictures of my development process

Here I am testing my slope detection algorithm

The Final Result!

My AI and I go play on the landscape’s steepest slopes!

This video demonstrates my Navmesh-free AI pathing system!


This is pretty cool, I actually had some broken terrain collision in 4.1 that I couldn’t figure out the cause of… Character collided fine but not physics objects.

Have you been testing tiled heightmap import yet? So far I’ve found it doesn’t put the tiles in the correct place(I.E in 2x2 the top left/right are the bottom left/right instead), and creates proxies after the first tile imported. I’ve been falling through the world on the adjoining seams sometimes.

How does the plugin work as far as multiplayer client/server functionality?

Thanks again as usual !

You’re welcome!

Multiplayer works in my latest version, if you have any issues with current version let me know!

You won’t be able to compile shipping / packaged builds of your game with this plugin yet, I am trying to work with Epic on this issue. :slight_smile:

It’s pretty complex because of the way UTexture works in pre vs post shipping builds.

Hi ,

Firstly let me say I’m sorry we still haven’t managed to track down the cause of the collision bug. We have spent a lot of time trying to reproduce it enough to be able to debug it, but it’s pretty slippery!

We will continue to work on it, but in the mean time I see you’ve implemented a very creative workaround :slight_smile:

I’ll reply about your request to make this work in shipping builds in the other thread.


AnswerHub is currently acting up and it’s preventing me from logging in (we’re working on it!), but I thought I’d post my reply here until it’s working:

Hi ,

As you’re probably aware, enabling LandscapeDataAccess in shipping builds would also require enabling a lot of editor-only functionality related to the texture source data that we really can’t include in a shipping build (for size reasons).

I do have plans to enable landscape deformation at runtime (to functions and blueprints), so I’ll have to find a solution to this. But until then, I do have some suggestions for your workaround:

Even without LandscapeDataAccess, in shipping builds you do have access to the PhysX RBHeightfield. This is the PhysX’s data structure holding the height data and we generate it from the texture height data in the editor. It should be possible to get everything you need from there. There is an example of how to extract that data as it’s used for the runtime navigation mesh generation. Look at the ULandscapeHeightfieldCollisionComponent:: DoCustomNavigableGeometryExport function and the ExportPxHeightField function Engine\Private\AI\Navigation\RecastNavMeshGenerator.cpp. You can do something similar to extract the triangle data from the RBHeightfield.

Another thing you might like to consider would be to convert your ULandscapeHeightfieldCollisionComponents into ULandscapeMeshCollisionComponents at cook time. That would completely solve the problem because the ULandscapeMeshCollisionComponent uses a PhysX trimesh, just like static meshes and BSP.


This is music to my ears! Hope that includes multiplayer support(as I have seen in other games). Will work great for free form house placement when you want to have a lot of uneven landscape. Same goes for building roadways via terrain alteration.

Also brings something crazy to mind like the game “From Dust”, which if I’m not mistaken was based on layered material based heightmap deformation:https://youtube.com/watch?v=uuJtUpN8e0Ehttps://www.youtube.com/watch?v=LBaNLY0dPNE

Sorry about that Detour ! :slight_smile:

Dear ,

Oh wow, very nice to hear from you !

I am actually still testing my creative workaround!

My main problem is that custom collision for the dynamic mesh code as shared in the custom mesh plugin by Epic doesn’t seem to work in cooked games.

Which of course means I dont really have a real solution for a final product :slight_smile:

I agree the collision bug is slippery!

It happens 100% for my main project, and is easy to reproduce.

I made a new landscape in a new 4.2 project , 3rd person c++ template, and I could not reproduce it!

Then I made a new 4.2 landscape in my main project and I reproduced it on the very first slope I tried to climb on the new landscape.

If you ever need my project to have easy repro just let me know!

Another thing you might like to consider would be to convert your ULandscapeHeightfieldCollisionComponents into ULandscapeMeshCollisionComponents at cook time. That would completely solve the problem because the ULandscapeMeshCollisionComponent uses a PhysX trimesh, just like static meshes and BSP.



Could I get a bit more specific details on this idea? I can use my current solution for pre-packaged builds and your solution for cooked builds if I can figure out exactly what you mean for this guaranteed cook-time solution :)

If the solution you mentioned is guaranteed to work, how is it different then what you are currently doing? Is there data I need to calculate or is it a simple conversion process?

A bit more details on this guaranteed solution would be lovely, cause I definitely need a guaranteed solution right now :)

Thanks !

Dear ,

I have made a new project in 4.2 and I am able to reproduce the landscape collision bug very reliably.

I also have proven that my plugin method does not work because the dynamic mesh collision is not getting cooked.

So I officially dont have a solution for the landscape collision issue aside from getting further details on what you’ve recommended in this thread :slight_smile:

**Project Available For You**

I can give you the packaged and unpackaged version of my new project, which packages quite fast, if you would like a complete example project that can reproduce the bug reliably!


[FONT=Comic Sans MS]I Have Amazing News!

** Porter has fixed the Landscape Collision Issue, with help from Zak Middleton!**

After a battle we’ve all been fighting since Beta5 we have emerged Victorious!

Porter deserves many flowers and butterflies sent in his general direction!

A Very Wonderful Thing Has Occurred Today!

And, best of all,

this fix will be in the next engine release!

For those who can compile their engine locally, here is the fix!