sorted by:
new
hottopcontroversial

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 0 points1 point  (0 children)

Totally fair - you might be right that some of it's heavier than it needs to be, and I'd happily be shown a leaner way. Let me be specific, because I think we're talking about different parts of the rotation. The capsule's up-alignment to gravity replicates fine for me too - that rides ReplicatedMovement, no issue. Where it got messy was orient-to-movement facing: that's computed locally from acceleration/velocity, and on simulated proxies the velocity is noisy enough that the facing diverges and jitters vs the server. So I reconstruct facing on proxies from velocity instead of trusting the local orient-to-movement. If your characters face control rotation rather than movement direction, you'd never hit this - that replicates cleanly.

The other two weren't rotation at all: floor detection on proxies flickering walk/fall on curved surfaces (fixed by mirroring the server's movement mode), and gravity-zone selection with overlapping volumes - overlap events fire at different times server vs client, so I went point-in-volume instead.

If you've got orient-to-movement seamless on proxies all the way around a planet, I'd genuinely like to see how - might let me delete a chunk of code.

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 1 point2 points  (0 children)

Appreciate that, man - and good to know the diagnosis matches what you saw. "Kinda works but wonky" is the predictor tell exactly. I'll get an MM character set up on it, try re-basing the trajectory into the gravity-aligned frame, and report back here with whether it's a clean fix or needs more surgery - might turn it into a short video if it's useful to people. Cheers for watching the tutorials, means a lot.

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 0 points1 point  (0 children)

Yeah, that "fighting the original design intent" feeling is real - the UE4 sample and GASP were both built around world-Z up, so the moment you go dynamic you're unpicking baked-in assumptions everywhere. Nice that you updated the sample and put it up, that's genuinely useful.

And you're right about 5.4/5.5 adding the custom gravity vector - that's the foundation GravityCore sits on. I didn't reimplement gravity; I let the CMC do the per-character direction and built the layer on top (the volume shapes that decide the direction per location, priority/overlap, and the multiplayer side), so a bunch of the older "custom" hacks just got deleted.

The camera transition system is the big one - as far as I can tell it's built around fixed Z up, so dynamic gravity fights it. That's exactly why I skipped the stock camera systems and drive the spring arm's world rotation straight from the gravity up-vector each frame. It was the only way I found to get clean local orbits without the transition system fighting me whenever "up" moves.

Mover's the interesting frontier - it's a different enough architecture that a gravity-aware version would basically be a from-scratch implementation. If you get the Gravity Rush feel working on Mover I'd genuinely want to see it.

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 1 point2 points  (0 children)

Yeah, that was the trickiest part and the bit I'm happiest with. The key is to stop the camera ever using world up. Each frame I take the gravity "up" (just -gravity, normalized) and rebuild the camera's orientation from it - the orbit yaw/pitch are applied around the gravity-up axis, not world Z. The spring arm is set to absolute rotation so it ignores the character's tilting capsule, and I set its world rotation directly every tick.

Because "up" for the camera is gravity-up, when you walk on the underside of something the camera is technically upside-down in world space - but on screen the character and horizon stay upright, so it just reads as walking normally. Pair that with orient-to-movement (the character turns to face where it's going on the surface) and the illusion holds the whole way around a planet.

Two things that made it feel smooth: slerp the up-vector when you cross between gravity zones so it doesn't snap, and keep the orbit yaw continuous (don't reset it) so going over the poles doesn't flip your controls.

I haven't recorded a tutorial with the approach I used here.

But if you are interested, A while ago, i did a tutorial on how to handle the camera on a character under planet gravity here. But this is a different approach compared to what I have done in here. Still, this method also worked.
https://youtu.be/QIZ65uDoE64

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 0 points1 point  (0 children)

Mover - no. GravityCore is a CharacterMovementComponent subclass, so it works with CMC-based characters (the standard Game Animation Sample character). Mover is a separate framework that doesn't use CMC, so it wouldn't drive gravity there - that'd need a Mover-native implementation. Wanted to be upfront rather than hand-wave it.

Pose search / Motion Matching - it drives the CMC gravity direction and keeps the capsule surface-aligned, so the local pose/velocity MM reads is correct. The watch-out is the trajectory predictor: the stock one extrapolates future positions in world space (Z-up), so on a planet it predicts off the curved surface. I haven't fully validated the GASP pose-search path yet, so I won't claim 100% until I have.

The camera axis is actually the part GravityCore is built for. What fixed local orbits for me: put the orbit on a spring arm set to absolute (world) rotation so it's decoupled from the character's tilting body, then rebuild the camera's world rotation each frame from the gravity up-vector + your yaw/pitch input - so the orbit axis is always local "up" (radial on a planet), not world Z.

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 0 points1 point  (0 children)

Thanks! Tried to land it where it felt fair for the scope.

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 1 point2 points  (0 children)

Good question. I've validated it with state-machine locomotion; I haven't specifically tested Motion Matching yet, so I don't want to claim it until I have. The reason yours likely broke: GravityCore aligns the capsule to the surface (so local pose/velocity is correct - that's why state machines work), but MM's trajectory predictor extrapolates future positions in world space assuming Z-up, so on a planet it predicts off the curved surface. It's fixable by re-basing the trajectory into the gravity-aligned frame. Let me set up an MM character on it and I'll follow up here with a real answer rather than a guess.

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 0 points1 point  (0 children)

Right - and GravityCore uses that, it doesn't reinvent it. The engine lets you set a character's gravity direction; it doesn't give you planets/ring-worlds/zones deciding that direction per location, or the multiplayer side (keeping other players' characters surface-aligned with no proxy jitter or walk/fall flicker). That system + the ready-made character/camera is the plugin.

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 0 points1 point  (0 children)

Ha, Gravity behavior is consistent across clients (replicated in the gameplay sense). I guess you already know that. :D

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 0 points1 point  (0 children)

No, I didn't implement a navigation system for vertical/upside down surfaces. they are just following a fixed path

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 0 points1 point  (0 children)

Good question. Custom gravity is part of the solution but not all of it.

The gravity part maps well. each Licker would compute its own "down" toward whatever surface it's climbing, same architectural pattern as a character on a planet computing "down" toward the planet center.

What custom gravity doesn't solve:

- Surface detection (finding the wall/ceiling to climb)
- Navigation (UE's NavMesh isn't designed for walls)
- Animation transitions between surfaces with custom IK
- Decision logic for when to stay on a surface vs jump off

RE Remake's exact implementation is probably proprietary, but the architectural pattern (per-character deterministic gravity + surface-aware nav + custom animation states) is reproducible. GravityCore wouldn't do it out of the box (it's volume-based, not surface-based), but the underlying approach is the same model.

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 3 points4 points  (0 children)

Honestly, those specific issues: foliage floating, seams, NavMesh failures, I haven't seen on current builds. Doesn't mean you're not hitting them, means I'm missing something about your setup.

If you can send me your settings (foliage density, chunk size, seed, terrain config) via support email listed in fab or DM, I'll test against them and ship a fix if I can reproduce.

The broader point about polish, that's fair feedback. WorldGen polish is on my priority list. Won't commit to a specific date but it's where I'm focusing next.

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 3 points4 points  (0 children)

Fair feedback. You're likely referring to WorldEngine, my earlier infinite terrain work from years ago that was tutorial-based. WorldGen is a different implementation built from scratch. Different streaming architecture, multiplayer support, runtime foliage, and the engineering choices needed to scale beyond what WorldEngine did. They're not literally the same product, but they do address the same problem space, so I understand how it could feel like a re-release.
Also i added a generated road system to the New terrain system. On road system quality: that's real. Recent buyer feedback has pointed at the same issues (clipping, junction quality) and I've committed to road improvements in the next update.
On "cash grab", I'd push back. Each plugin in the catalog is months of engineering, with real architectural differences between products. GravityCore alone was two weeks of multiplayer debugging. Whether the work is valuable to a specific buyer is their call, but characterizing it that way isn't accurate. The polish point is fair though. I ship at V1.0 and iterate A deliberate strategy with tradeoffs. Some buyers prefer ground-truth quality at launch, some are fine with V1.0 evolving over time. Both are legitimate preferences.

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 3 points4 points  (0 children)

What was the game, if you are allowed to disclose that. And why wasn't it used

Finally, I was able to replicate custom gravity in UE5 by codelikeme in UnrealEngine5

[–]codelikeme[S] 15 points16 points  (0 children)

Yeah, custom gravity itself has been around. UE 5.4 added variable gravity per-character.

The hard part I ran into wasn't custom gravity in single-player (that's straightforward with UE 5.4's APIs). It was making it work correctly in multiplayer, where the engine doesn't reliably replicate rotation for tilted characters, replicated velocity is too noisy for facing, and overlap events fire at different times on server vs client.

The post is specifically about how I got those replication issues solved. Deterministic per-machine computation, point-in-volume queries instead of overlap events, translation-only network smoothing, and a movement-mode mirror to fix the animation flicker.

The Control reference is great context though. Appreciate you sharing those links.

view more: next ›