Terrain editing in runtime

This is a feature that I’m surprised to see not implemented.

Coming from Unity where I could whip up terrains at will during runtime, change heightmaps, manipulate materials and do just about anything from code I find it strange to not be able to do anything of the kind in UE4. This is pretty vital to large scale games where you need to generate terrains while the game is playing and creating them by hand is practically impossible, or you want the output to be randomized. Currently the only option would be to manually create the meshes for the ground, which isn’t ideal at all, we lose all the advantages that the built-in terrain would bring with it.

Please, please let us alter terrains from code!

and from blueprint :wink: I would also really appreciate this feature.

Sorry about that. This feature is interesting to me as well. We’ve seen some developers get in-game heightmap and material modification working with only minimal changes, but it requires linking with editor-specific code which is not currently allowed to be in a released game. From my understanding of how it is all setup, we’d need to do a fair amount of refactoring to get the core terrain spawning and editing features available in game at runtime. I’m hoping we’ll have time to work on this though! If you guys end up digging in and getting this working, we might be able to collaborate!

2 Likes

I’m afraid I do not have the time nor the skill to start modifying the engine code - I was hoping you guys could give this issue some more attention. It is a big one in my opinion and should be addressed. It’s currently one of the big walls I’m facing with this engine and I’m not really finding any way around it.

I also have by far not the skill to do this myself… I only use blueprints :smiley:

I guess that translates to “not enough requests for Epic to bother and spend some time to do it” ? If you guys ever consider doing it, could you also make foliage painting available at runtime ? It just seem sensible to make all these features available in runtime, considering so many games today ship with a “world” editor.

So, if I understood you right you’re saying that the terrain editing code is in the editor (and that one’s not allowed to link to editor libraries in a built game) and therefore not available runtime? Is there any limitation why it couldn’t be put into the game runtime library, or was this just a design decision at the time to put all the terrain editability into the editor code?

Out of curiosity I did download the sources and peeked into the Landscape files, but understanding what’s happening and where takes some time and feels quite overwhelming - the related code is spread all over the place.

Actually almost all of the code you need to dynamically create landscapes and edit them is in Runtime code, but some of it is not fully initialized unless you are running the editor. The files you want to be looking at are LandscapeEdit, LandscapeDataAccess, LandscapeInfo, LandscapeProxy, Landscape and LandscapeComponent. These have pretty much everything you need to be able to create new landscapes, edit heights, update collision and change materials, and they’re all in Runtime code. An example of a problem you’ll run into right now though, is a large number of useful functions in those classes are decorated with “#if WITH_EDITOR”. For example the ALandscapeProxy::Import() function is very useful for creating a new landscape out of some initial raw height data and materials, but it’s compiled out in the game unless you go and modify that source code and recompile the engine.

Thanks for the information! Just to clarify though, if I was to make these changes, would I be allowed to use the modified engine in a released game? (you mentioned “*but it requires linking with editor-specific code which is not currently allowed to be in a released game. *” in your earlier post)

We only restrict shipping with code compiled from source files under the Editor and Development subfolders. You can modify the engine to remove “WITH_EDITOR” and “WITH_EDITORONLY_DATA” checks as you see fit for your project. However, there might be some other reliance on editor code under the hood there, I’m guessing you will need to do some fix up here and there to get it fully working. I would start by looking at any Landscape runtime code that checks GIsEditor. In my earlier post I didn’t realize that most of the Landscape creation and editing code was actually in the Runtime folder already. Let us know how it goes! As I said earlier, ideally could benefit from having access to terrain creation features in their game so we might be able to get the changes merged back in.

I would like to see this feature natively implemented, It´s one of the most interesting thinks I was missing on UDK

At absolute must !

The GDC 2015 as you are probably all aware by now ! has thrown up this Unity 5 v Unreal 4 challenge race. I’ve been utterly impressed by both of these companies to focus on the indie market more.

I do have to say though that not being able to change the terrain at run time is rather lame for unreal. How many games use terrain probably halve of them today, and you cant do this ? Another point for Unity 4, 5.

Cubiquity

These guys seem to be working on the right track…it’s not so much landscape editing at runtime as creating a mesh and editing it through their own custom blueprints…

https://forums.unrealengine.com/showthread.php?29873-Cubiquity-for-UE4-Voxel-Terrain-Plugin

I think this would bypass the landscape limitations, especially from the progress videos they’ve made…I’m so eager I’m checking that thread and the twitter feed regularly.

Is there any process on this?

I would love to see this feature as well

Any news for 4.9?

I need this feature also, please include it in futuro release.:slight_smile:

+1

I’m in the same situation here. I would appreciate if you guys add this feature.

Has anyone gotten around to doing this yet as I’m rather interested in the possibility of dedicating some of our development resources to help out with the development of this feature but we will probably not be able to start work on such a feature effort until AT LEAST October 2015…

If someone has in fact already started a GitHub fork for this feature than I would be very interested to follow its development to get a lay of the land prior to us potentially jumping on board the development effort.

With the current wording of the EULA, is it still a problem to use code that lives in the previously “forbidden” source folders?