[Please Dearly Consider] Exposing Runtime/LandscapeDataAccess.h To Shipping Builds

Development Programming & Scripting
1

Dear Friends at Epic,

To work around the landscape collision bugs that still have not been resolved I used Landscape Data Interface to add collision triangles where they were needed, along sloped terrain sections.

You can see videos and even see the source code for my plugin here:

My system relies on LandscapeDataAccess.h, which is entirely wrapped in a IF WITH EDITOR

My packaging process failed because of this.

LandscapeDataAccess is indeed located in the Runtime section though!

#Request

Could you consider exposing LandscapeDataAccess.h to shipping builds since the proper solution for the Physx 3.3 landscape collision issues has not been found yet?

I have a solution that works for me but I can’t use it without LandscapeDataAcess.h

I can’t ship my game without a proper solution for Landscape collision Physx 3.3 issues!

Thanks for considering this!

2

Hi ,

As you’re probably aware, enabling LandscapeDataAcess.h in Shipping builds is a bit problematic because it drags in a lot of editor-only functionality such as texture source data that really shouldn’t be in Shipping builds (for size reasons).

I do have plans enable landscape data deformation at runtime (and by blueprints), so obviously I will need to find a solution to these issues. But until then I do have a couple of other suggestions that I can give you now:

At runtime you do have access to the RBHeightfield which is actually just the height data used by PhysX. You can extract that data to get pretty much exactly what you’re getting out of the texture with LandscapeDataAccess. The realtime navigation mesh generation code uses this. Have a look at the ExportPxHeightField function in Engine\Private\AI\Navigation\RecastNavMeshGenerator.cpp which extracts the data. This is called from the ULandscapeHeightfieldCollisionComponent::DoCustomNavigableGeometryExport function.

You could write a similar function that extracts the triangle data you need out of the RBHeightfield stored in the collision component.

An alternative you might like to consider to work around this problem, would be to add a function at cook time which converts the ULandscapeHeightfieldCollisionComponents to ULandscapeMeshCollisionComponents. These are slightly bigger memory-wise but there would be no runtime cost.

Cheers

3

“I do have plans enable landscape data deformation at runtime (and by blueprints), so obviously I will need to find a solution to these issues”

Oooh that is going to be awesome!

I want runtime landscape deformation so much!

Thank you for working on this Porter!

:slight_smile:

And thanks for all your helpful suggestions!

I have copy-pasted your message to my notes files and will work on this!

#Thank You Porter!

#:heart:

4

Dear ,

You mentioned in your very nice forum post that you have trouble reproducing the landscape collision bug, and I agree, as I shared in the post.

But I can easily and reliably reproduce the bug in my main project, so if you’d like my entire project to aid your debugging let me know!

#:heart:

5

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


**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!
6

Hi ,

It would be great to have the 4.2 project that reliably reproduces the problem.
If you want you can send me a link or you can upload it to our write-only FTP server:

user:
pass:

Thanks

7

#My Project for You

Dear ,

I am uploading my project to the drop box you mentioned above

ForJackPorter_JoyShapes_FromRama2.rar

the first attempt can be deleted :slight_smile:

#Expected File Size

Total file size should be:

1.03 GB

1,107,251,319 bytes

#Important ~ Char Mesh ~ File 2

I didn’t finish zipping apparently, to see the character mesh you need this additional Content .rar

ForJackP_TheCharacterMesh_FromRama

It is already done uploading

File size:

750,141 bytes

#Time Done

Upload should be finished within 4 hours of me sending you this message.

#Source

I’ve included my source and .sln so you can rebuild the project entirely if you want :slight_smile:

#Running

I left a .bat file that you can run if you edit it to point to your 4.2-Release engine.

#In-game Note

I left you an in-game note!

I point you to a great spot to test!

#Testing

Just jumping around on the slope I’ve pointed out leads me to reliable falling through within about 1-3 attempts

#Character

It is a simple skeletal mesh with a simple collision capsule, all default settings from Third Person C++ template.

I am not doing anything fancy in the C++ regarding the character movement or collision

All the c++ is actually for the UI and camera at the moment

#Verifying

I’ve re-unzipped this project to an external hard drive and can verify that it will run if you simply set the .bat file to point to your engine

I’ve also verified falling thru the landscape more than 5 times using the version I am sending you, you just jump around on the slope I pointed out to you and it should not take long, especially at certain spots where it is steeper.

8

#Good Luck!

Good luck , keep me posted on your discoveries!

#:heart:

9

Dear ,

Did my project transfer correctly? Where you able to open it?

Have fun today!

10

Hi ,

I was able to download all your content and open your project.

The game code had some problems with FBox and some header rearrangement we’ve done recently but I’ll hack it enough to get it loading.

Cheers

11

I was able to get it running easily. I was easily able to fly through the landscape right where your text component indicated, so this should be much easier to track down.

About the source - for FBox2D, you don’t need to access Min and Max directly, instead you can use Box[0] and Box[1] respectively. We also recently changed the headers so less stuff is included automatically, so I had to add a few more include files - heads up for when you get 4.3.

With some luck, hopefully I can get a fix for the landscape collision included in it.

12

"About the source - for FBox2D, you don’t need to access Min and Max directly, instead you can use Box[0] and Box[1] "

Ooh nice, thanks for the tip!

I was actually the one who submitted FBox2D to the engine via GitHub ( at James G’s request) :slight_smile:

So I hope you are enjoying it!

“We also recently changed the headers
so less stuff is included
automatically, so I had to add a few
more include files - heads up for when
you get 4.3.”

Any chance you can tell me what those headers are so I can prepare in advance? It took me a long time to convert my main project to comply with 4.2 Thanks !

“With some luck, hopefully I can get a
fix for the landscape collision
included in it.”

#Pleaaase Thank you P!

13

To give you an update - the problem seems to be highly framerate dependent, with higher framerates cause it to happen more. It’s harder to reproduce in debug builds which are generally slower.

If you launch the game with -UseFixedTimeStep, it will tell the physics system you’re running at 30 fps regardless of the real frame rate. With that option, you can see it’s much harder to make the problem occur.

I’m still trying to work out what to do about it, but it gives us something to go on.

14

#Woohoo! P is near to Victory!

I can happily verify that I had the same experience you describe !

I tried your suggestion and I literally got bored of trying to get the character to fall through the landscape! I could not get it to happen once!

Woohoo!

You are on to something !

I am wishing you every success!

#:heart:

15

Hi ,

I have a fix for the landscape collision issue.

Please replace the entire ConvertOverlappedShapeToImpactHit function in
Engine/Source/Runtime/Engine/Private/Collision/CollisionConversions.cpp with the contents of this text file (two functions). This fix will be included in 4.3.

Basically the problem is when you begin to get embedded in an object, PhysX needs to be told how to push you out again. There was special code to calculate the best direction to push out for triangle meshes, but none for heightfields. I added the same kind of handling for heightfields.

(I can’t take the credit as one of our engine programmers, Zak Middleton pointed me in the right direction)

Please confirm this fixes the problem for you :slight_smile:

Cheers

link text

16

Porter You Are Victorious!!

It wooorkkkeed!!!

It woooorks!!!

I’ve tested my two different projects that experiences the issue and 3 different characters, one who has a positively tiny collision capsule!

They all work!

#It wooorks!

P!!!

Rainbow for You!

2537-rainbow.jpg

#Zak Middleton!

Rainbow for you for helping out!

2537-rainbow.jpg

P!

Another Rainbow for you for finding the solution to this issue! It makes perfect sense in hindsight, it is the perfect and Beautiful solution!

2537-rainbow.jpg

#Victory to You P!

#:heart:

PS: I am going to go spread the news of your Victory! :slight_smile:

PSS: Epic, P deserves special rewards for this!!!

17

This is back in 4.7.1…

18

Hi Guy, sorry to hear you’re seeing issues with collision in 4.7.1.
This old thread you replied to is very confusing and contains a lot of old information, and the specific issue it was discussing has been resolved.

Could you please post a new question describing what you’re seeing in 4.7.1, and I’ll take a look.

Thanks

19

Great to hear from you !

Thank you for Landscapes!

I hope dynamic height map changes in packaged builds are still in the works!

Have fun today!

#:heart:

20

Still an issue in 4.18.2