Terrain editing in runtime

+1 I would really like to see this feature.

The only thing that makes me not fully switch our game to Unreal Engine yet. Runtime terrain modification is almost in 50% of games nowadays. (In-Game Map Editor, Voxel Terrain, Procedural random map generation, etc). I hope they work on this soon as it will allow a lot of developers I know switch to using Unreal(The Forest).

Why games as the Forest will move to other engine when the game is near and in Steam? Each engine got their pros and cons, no one is perfect.

Absolutely necessary, was shocked that ue4 cant do this, especially since unity can do it so easily.

+1 [FONT=Arial Narrow]’ ’ ’ ’ ’ ’

I’ve tried to implement runtime modifications of terrain materials and I ended up banging my head against a wall for 3 days before giving up. Definitely not a quick modification…

Unity has its own terrain problems but modifying the terrain height field at runtime is totally possible, unreal really should get this sorted out.

And its disappointing that 2016 and still no **** native smooth voxel terrain implementation in any game engine.

Hi everybody,

I could not find the entry in the roadmap (UE-2341) mentioned by , any idea where it went ?
Procedural terrain generation is a must for our current project, unity does that well but we wanted to work with UE4 :frowning:
If I find a proper plugin to do terrain instantiation and editing in real time, I will post it here :slight_smile:

MAJOR BREAKTHROUGH IN THE AREA OF DYNAMIC TERRAIN SIMULATION!

Watch out Epic, the competition doesn’t sleep. I just learned that a team of developers calling themselves “Bullfrog” have the impossible and developed a landscape that can change BOTH shape and materials at runtime!

Here is the evidence: https://www.youtube.com/watch?v=m3zsPl4Ampw

I know this is all very new and difficult still, but perhaps Epic could try and catch up with this new development over the next four or five years?

This is alien technology :smiley:

Yeah, It is really fantastic!:smiley:

@MaxPower42 - cooool! :smiley:

to be honest, a year ago I was absolutely sure this feature would be ready by this time… instead, there are only a few user made substitutes in development utilizing procedural mesh, but until now (as I know) these are purely procedural without editing possibilities like landscape has.

personally I would need only to smooth little areas for RTS building placement, and moat digging at walls, nothing extra. fortunately, Rama’s tiled level loading pull request has been accepted and will be included in 4.13, which matches partially the requirements of my game…

Who are these ominous masters of the east you speak of? Sony bought Epic or something? D:

I don’t want to start a new thread and it has to do with Landscapes, too.

What about real Sculpting of Landscapes?
Have you seen Just Cause 3? Landscapes have overhangs and “real” caves. Not just a “Hole” in the landscape and staticmeshes to fake a cave.

Hey , I wanted to just let you know I’m keeping an eye on this thread for all this new feedback, ideas and interest. It really helps Epic to understand what features are still important to Unreal devs and that can shape the future roadmaps for the engine. Please keep the feedback coming and thank you for being passionate about improving the engine :smiley:

We really love this engine and understand too many tasks in your development priority list. Is there any process on this feature? :smiley:

I’m interested in this, or any extra landscape interaction possibility. Being able to adjust tess, or material instance, anything really to get some more meaningful interaction with the landscape in the game world.

Does anyone have a workaround for changing a landscape’s entire material or its textures at runtime? I’m not even talking about any landscape-specific height or weight data, just the material itself.

It looks like dynamic material instances don’t work with landscapes, and all the functions that could be useful are editor-only.

Suppose I want to represent the same landscape in different weather conditions (standard, snowy, rainy/wet …). Am I supposed to copy-paste the landscape into seperate levels and give the player a loading screen when it starts raining?

Can’t I (AT LEAST!!) change the whole material, if nothing else??

Use material parameter collection values to drive the parameters on your landscape material, their values are easy to access from code/BPs and they work on landscapes.

But there are no texture parameters in parameter collections :confused:

I mean it’s very nice, but I don’t see how I turn a grassy landscape into a snowy one by passing floats into the material… I wasn’t planning on simply shifting the diffuse color to full white or something. And I don’t really want to blend, because (if I understand it correctly) the number of samplers per material is limited to 16, and I need most of those. I mean, I can’t put every texture, diffuse and normal (and maybe specular), of every “theme” into a single material.

I am trying all kinds of hacky stuff with materials and textures atm, but I don’t suppose it’s any good. I would be happy if I could just set an override material for the landscape-actor (or its components), an override texture for the landscape material, or even switch resources of a source texture with that of another. I don’t care how dirty, I need to change landscape textures at runtime.

edit: I believe I found the perfect hack for my problem :smiley:
I iterate through all landscape-components and set their MaterialInstance-members (which are technically UMaterialInstanceConstant-pointers) to a new MaterialInstanceDynamic created from each component’s original MaterialInstanceConstant. This way, the dynamic materials should have all the height and weight map data still intact without the need of any further workarounds. Then I can set parameters (including textures) the way I want. You have to re-initialize the render data, of course. Everything that’s needed can be found in ULandscapeComponent::UpdateMaterialInstances(). There have been no crashes or anything so far. I guess the interfaces of the two classes (MIC/MID) are so similar that problems are unlikely.