[Please Dearly Consider] Exposing Runtime/LandscapeDataAccess.h To Shipping Builds
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!
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!
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.
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 :-)
answered Jun 25 '14 at 10:42 AM
Follow this question
Once you sign in you will be able to subscribe for any updates here