Sorry for the severely late response… I’ll take a look at what you’re talking about. Thanks for the input!
[=“bybw, post:28, topic:37461”]
To fix this issue for the landscape, you will have to apply the same contact offset to the landscape collision shapes in ULandscapeHeightfieldCollisionComponent::OnCreatePhysicsState.
eg. HeightFieldShapeSync->setContactOffset(MaxContactOffset);
[/]
I’m at the 4.21 fixed the meshes issue with the other engine change but the landscapes still giving the same issue, the solution you wrote don’t even exist.
Someone have a fix for the landscapes ?
Thank you.
1 Like
[=“, post:64, topic:37461”]
I’m at the 4.21 fixed the meshes issue with the other engine change but the landscapes still giving the same issue, the solution you wrote don’t even exist.
Someone have a fix for the landscapes ?
Thank you.
[/]
Got it fixed:
In the file LandscapeCollision.cpp:
extern ENGINE_API TAutoConsoleVariable<float> CVarMaxContactOffset;
then add the read of the var:
const float contactOffset = CVarMaxContactOffset.GetValueOnAnyThread();
HeightFieldShapeSync->setContactOffset( contactOffset );
Thats all!
Edit:
Now there is just a problem, the whole ball vibrates over the landscape surface 
The only way I found to fix it is hard fix the contactOffset value in the code to 0.05, for some reason isn’t reading it properly
Edit #2:
if you use const float contactOffset = UPhysicsSettings::Get()->MaxContactOffset; should be fine
Edit #3:
Made a pullrequestgithub.com/EpicGames/UnrealEngine/pull/7653
Do you need to do all three steps? I changed the value of the variable const float ContactOffset = ComputeContactOffset(Geom); + what is in the pull request and now there is vibration on both cubes and landscape
For the future landscape users with this issue…
After setting the ContactOffset to values suggested in this topic,
Click on the Landscape
Go to Collisions
Set “Collision Thickness” to a much lower value. 1 worked for me
Test physics
The ball should now roll perfectly smoothly. Tested on UE5 - however I did disable chaos solver earlier while trying to find a solution so this may or may not have an effect.
[=“THEAETIK, post:67, topic:37461”]
Click on the Landscape
Go to Collisions
Set “Collision Thickness” to a much lower value. 1 worked for me
Test physics
[/]
Yea dont.
Objects will be 10000% more likely to just fall throguh your landscapes. Thats pretty much all you are able to achive by reducing the thickness value.
Just as a follow up to the issues that I was having with this, I opened up my project from 4.21 to 5.1 and it just works. I didn’t change anything, so there you have it… I’m sure there were some of you out there losing sleep! LOL!
Thanks Epic!!
1 Like
In UE5.3 this issue reappeared. Changing offset settings has no effect. Anyone has any ideas how to fix this on 5.3 version?
this has been an issue for a long time, with multiple solutions that people are trying to get into engine, but it doesnt seem that things get fixed.
I will investigate earlier versions to see if same things happends, if they are there too I will actually have to learn myself another engine I suppose…
This issue reappeared in version 5.3, when I adjusted the ContactOffsetMultiplier, but it only improved, but the problem remained.
2 Likes
MinContactOffset, MaxContactOffset, ContactOffsetMultiplier aren’t used by Chaos physics at all! I’ve checked UE5.3 engine source code, they are remains of PhysX.
I think you may all be better off working the problem some other way - particularly with chaos.
For instance, one could make a spline mesh for the ball to roll on.
The different parts of the spline mesh should always be pefectly aligned collision wise, eliminating jumps or issues.
Another option would just be to test a few frames ahead of the ball to detect the landscape transition, then store the collision position you are reading, disable physics as soon as you are 1 frame away from the new landscape, move the ball to the other landscape manually using the stored positoon you tested collision for, and r-e acrivate the simulation while imparting the same speed from before the whole operation.
If the scope of the whole game is a sphere rolling around, then stuff like this on every mesh surface transition would ensure your travel did not get effected by something below a custom treshold you can eventually define / look up.
As always, with Physics you cannot rely on the engine to work, so you have to do at least some of the work for the engine…
pff the fix on physics x is pretty easy, but you would need to make your own engine as the pull request for fix is just overlooked.
And you cant really expect indie devs to go making their own stuff the first years.
nah, they should have fixed this in 4.27 first of all and then kept in 5…
Seriously?.. Ugh!.. I’ll open up my old file and see what’s going on. SONOFA!!!
I can confirm that this is still an issue in 5.3.2. I haven’t updated to 5.4 yet (I doubt it’s fixed, but I’ll give it a go). Also, I can confirm that any values (no matter how small) for Min Contact Offset and Max Contact Offset do not resolve the issue. Implementing a golf game and this has me on a two-week workaround for putting. Wooo.
I just jumped into the 5.3.2 source code and it appears that the min and max contact offsets are clamped at appropriate values. I’m not sure why it’s not helping, then, so I’ll keep digging. But if anyone else knows, please do let me know.
UPROPERTY(config, EditAnywhere, Category = Simulation, meta = (ClampMin = "0.001", UIMin = "0.001"))
float ContactOffsetMultiplier;
/** Min Contact offset. */
UPROPERTY(config, EditAnywhere, Category = Simulation, meta = (ClampMin = "0.0001", UIMin = "0.0001"))
float MinContactOffset;
/** Max Contact offset. */
UPROPERTY(config, EditAnywhere, Category = Simulation, meta = (ClampMin = "0.001", UIMin = "0.001"))
float MaxContactOffset;
It’s probably chaos thats creating chaos.
If you manage to swap a source build back to physx you probably won’t have any issue at all.
And as far as fixing chaos gos, good luck. The name was purpously chosen to make a mess of something that worked / the whole engine.
Just an update on this for anyone who stumbles onto this thread. I managed to fix this (at least, so far) by setting the value of the Max Substep Delta Time (in Project Settings → Physics) to 0.0013. Doing this completely solved the issue. However, this does affect performance, so I’ve optimized everything where possible (only using CCD when necessary and otherwise clean/optimized code when it’s on). But this did not require any engine source code changes, nor any complex workarounds. It’s not the best option, but it works.
1 Like
and this is still working?
It never did.
Setting substep works for that specific computer on that specific processor.
Anything that is slightly slower will likely have the very same issue.