Terrain editing in runtime

anonymous_user_99a01d72 · February 15, 2016, 9:48pm

+1
We need this and is why I was a bit worried when the old terrain system was away with as it might have been basic but had its uses.

John_Alcatraz · February 16, 2016, 3:14am

Let me say that I still really need this :o

VSZ · February 16, 2016, 10:06am

+1, this is a crucial feature for my game too.

Like others here I’ve also considered digging through the landscape editor code but experience tells me that mini-projects like these are deceptively challenging timesinks I also think as time goes on it may become more and more difficult to expose these landscape tools dynamically due to inter-dependencies with newer engine/rendering features so hopefully this can be achieved before it becomes too expensive (resource-wise) or technically unfeasible to implement this.

Is this feature on trello yet? I think it would get a ton of votes!

jmalaska · February 21, 2016, 6:23pm

+1! I’d even purchase it on the Marketplace for a reasonable fee

anonymous_user_3dfb2cf5 · February 23, 2016, 12:01pm

+1

Important feature, please add this!

rYuxq · February 27, 2016, 6:23pm

I don’t quite get how this answers the trello-question, in which I would be interested as well.
I can’t seem to find a ticket with that ID - through I am as unfamiliar with trello as one could be.

toryno · February 28, 2016, 9:07pm

+1 Please add this!

rYuxq · February 29, 2016, 8:21am

'[EPIC:

DarkVeil;202187’]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.

–

'[EPIC:

DarkVeil;202695’]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.

Does that mean: As long as those editor only variables are provided at runtime, then a good part of the landscape features would be available at runtime?? So if I go and create fake-data for those variables at runtime, it would be fine and all??

Qoning · March 19, 2016, 11:11pm

How is this not a thing? This is probably the second thing that comes to mind when you ask “What do you want to do with a terrain / landscape?” right after “Walking on it.”! I spent a while researching whether UE would be suitable for my project, but without this feature (actually supported and documented), the answer seems to be no. A shame, perhaps once this is implemented I can come back with a smile on my face.

Lodeman · March 21, 2016, 10:56am

This and grass-blocking-volumes would make the engine (almost) perfect for sandbox games. It would be great to get an update from Epic on the status of these features!

MaxPower42 · March 23, 2016, 6:08am

Aww, come on… how can an engine be so ahead in some areas and so crappy in others. So, if all the code is there and it only takes a few modifications to work without the editor, then why doesn’t Epic make it happen?

I badly need to modify heights, make/fill holes and modify material weights at runtime

I came to UE4 from Unity because I thought it would be better for procedural runtime-generated and runtime-modified levels and stuff. I guess I thought so mainly because of the dynamically updating NavMesh. But if you can’t even change the terrain…

LeamDelaney · March 23, 2016, 6:25am

If you can’t edit the terrain, then I guess god games are off limits?

Azarus · March 23, 2016, 8:14am

You could use the procedural mesh component to create your landscapes, that you can edit at run time. Isn’t that a solution?

MaxPower42 · March 23, 2016, 7:51pm

I don’t know if that’s a solution, but I highly doubt it will be nearly as optimized as an actual landscape, especially since you probably can’t create a PxHeightfield actor just like that.

rYuxq · April 3, 2016, 12:50pm

We dont know if it takes just a few modifications. If we really did, maybe someone from the community would actually bother to implement it xD Though I will look into it once I actually get to the point where I really need it

MaxPower42 · April 25, 2016, 6:49am

bump . . .

Slavq · April 28, 2016, 11:24am

+1, that would be a really neat feature.

JMcComb · May 17, 2016, 6:46am

Add me to the list of requesters for these features. Working around the issues caused by not being able to modify the landscape during play, is getting to be quite frustrating.

FilipeTessaro · May 17, 2016, 8:55pm

+1, we all need a feature like that, please add this feature

Nightmask3 · May 21, 2016, 1:30am

+1 come on Epic, don’t kill the hype train!