the long-term goal is to deform landscape based on spline components, so they mimic landscape spline functionality. I understand this must be done in an editor utility. Landscape splines are annoying and buggy (when interacting with pcg graphs) and I’m trying to build a toolset for someone who has no experience in game development. So developing a way that the spline deforms landscapes needs to be a seamless process in a way that landscape splines do this. my issue isn’t with the actual deformation process. my issue is setting up the references so that I do not have to rely on actor polling or extra buttons.
My best assumption is I need to cache all the splines in the editor utility blueprint then bind to a spline event. since actors can’t initialize editor utility blueprint functions. i thought using a utility actor component would be smart, but the parent actor cannot initialize the component functions, and the component has no construction script or events that i can find so how do they even communicate with each other?
the problem is caching the splines in the editor utility blueprint.
I’ve considered using an editor utility widget that has a ‘spawn spline’ button. it would be annoying to have to go to a fixed coordinates every time I spawned the spline or manually enter coordinates. If I did this, could I spawn the spline based on level viewport camera view?
Another option that has lead me to nothing but dead ends would be to just cache the splines as they are added to the level viewport… but from what i’ve found this just involves polling every time an actor is added. which i’m trying to avoid. as there does not seem to be any dispatchers that pass a reference of the actor that has been added.
which led to this option I’ve considered. from the actor’s construction script. grabbing a level reference. and dispatching an event from the level that passes the actor reference to the editor utility. I do feel like there should be a more efficient way of handling this though and i’m rather new to editor utilities.
I’m open to suggestions.
edit: i just had an idea. i just put the spline in the editor utility blueprint. then if needed copy the data over to dedicated spline management actor for runtime.
edit: with the edited idea now i’m stumbling to reference the landscape
edit: nvm. landscape patch plugin is just easier than Editor Apply Spline.
You don’t need polling — two clean options depending on what UX you want:
Manual pick: add a variable of the Landscape actor’s class to your EUW, drop a Details View widget in the EUW, and bind it to that variable. You get the standard actor picker dropdown — the user clicks the landscape once and you hold a hard reference, no loops.
Programmatic: use Get Editor Actor Subsystem → Get All Level Actors (or Get Selected Level Actors if your tool should act on the current selection), filter by class, and store the results once. Do this on tool open or on a button press, not per tick — that’s the ‘polling’ you want to avoid.
For your spline deformation tool specifically, a third option fits better: don’t reference the landscape at all. Put your splines in the level, and have the EUW operate on whatever spline the user selects — Get Selected Level Actors → filter for spline components, then run the deformation on each selected spline’s owning landscape. That matches how Epic’s own landscape spline flow works (select spline, act on it) and survives level streaming since you re-resolve selection instead of caching actor pointers that go stale on reload.
Also cache the Editor Actor Subsystem reference once at construct, not per call — repeated Get Editor Subsystem calls are cheap but the pattern keeps the graph readable.
that regen issue has a specific cause, and once you see it the fix is structural. landscape splines deform the heightmap through edit layers, and pcg has no idea the heightmap changed, it only watches inputs it actually sampled, like actors and their transforms. on top of that landscape splines are not spline components, so pcg’s spline data nodes can’t read them in the first place. you get a landscape that looks right and a graph that never knew anything happened.
the clean fix is to make your own spline actors the single source of truth. plain actors with spline components, tagged for pcg. your editor utility deforms the landscape from them (patch plugin is a fine choice), and pcg consumes the same actors through get spline data by tag. move the spline and pcg sees the component change and regenerates on its own, no polling, no buttons. the landscape spline layer becomes optional decoration or goes away entirely.
if you must keep landscape splines as the authoring format, mirror them: your editor utility keeps one lightweight spline component per landscape spline, synced on landscape edit callbacks or on save, and pcg reads the mirrors. more moving parts, only worth it if you’re attached to the landscape spline editing ux.
last resort for heightmap driven graphs: after deformation completes, trigger the refresh yourself. grab the pcg components once (get all actors, filter for the pcg component) and call request refresh on each. that is a one shot after an edit session, not polling, and at least it makes the graph honest about being stale.
given you already landed on the patch plugin, i’d go all in on your own splines as the source of truth. it also fixes the beginner toolset story: one object to select, everything downstream reacts.
so pcg’s spline data nodes can’t read them in the first place
just wanted to let you know that you’re wrong about this. not sure if its a newer feature fix or what but it definitely can in 5.8. you’re not the first person on here to tell me this as well so i’m guessing its changed. the only weird part is you have to reset the scale to 1 after the spline sampler. for some reason it jacks the scales up in the thousands.
but i’m not going to use them anyways. just thought i would let you know.
good catch, and thanks for the correction. you’re right that i was out of date: reading landscape splines directly into pcg landed in 5.6 (get spline data now accepts a landscape spline actor as its target), so on 5.8 that path works, and apparently more people have been told it can’t than actually checked. noted for next time.
that scale explosion after the spline sampler is a known quirk, not something you did wrong. landscape splines carry a huge mesh scale on their spline mesh components, and when the sampler pulls control point rotation and scale it bakes that into the sampled points. reset the point transform after sampling like you’re doing, or set the sampler to sample on spline points instead of distance if the scale junk is only at control points.
since you’re not using them anyway, the own-spline-actor setup stands: plain actors with spline components, tagged, pcg reads those, your euw deforms the landscape from the same actors, everything reacts without polling. the landscape spline read path is still worth keeping in your back pocket though: if you ever want the native editing ux back for authoring, you can read them straight into pcg on 5.8 and only lose the auto-regen benefit, which you’d handle with a one shot request refresh after deformation completes.
either way, the structural part of the original question holds: keep the splines as the thing the user selects and edits, resolve the landscape from selection at action time, and nothing goes stale.