Dynamic Terrain (updated, now with downloadable demo)

[Neongho]

Sorry for my direct, " post of "

but like you suggest, posts like this nowadays feel like showing off and only evoke "give me, I want" replies.

But this feature it's just awsome, and a feature that i always admired and i did not think it was possible in UDK just unrealscript, it's not the thing that i want to use it, " wich ofc i would like to make use of it in some projects " but, all the knowladge and craziness that it's behind of it.
Well atleast give some reasonable points, on how you did it, this way i would try it myself, and i would be more satisfied than even copy pasting and understanding :P.
Key point, " is this all modifying a MIC, wich is assigned on the landscape material ? And then changes are applied due to the change of the MIC params?

[Chosker]

Well atleast give some reasonable points, on how you did it, this way i would try it myself, and i would be more satisfied than even copy pasting and understanding :P.

that's exactly the attitude I miss

[UnrealEverything]

People who can't do this will want your work if you post it, if you don't share it then you are merely using the forums for shameless self-promotion.
You have been here for 6 years, you don't need to do the latter, your work speaks for itself, but you should accept that people will want this if they cannot do it themselves, if you withhold it, they will no longer show an interest.

- It's a natural double -edge from development that we all face at one time. Unless you seek profit or employment i suggest you make it open source.

- maybe consider creative commons for a starting point, at least then you can share it and stick it under the umbrella of intellectual property + you have us (the community) to back you up if anybody tries to steal your work or profit of it.
That's what being a community is and should be ...
Tis a cool project

Thank you very much for the tips and hints.
The UDN licensing page, in the business and legel section here: http://udn.epicgames.com/Three/Devel...%20and%20Legal, tells me I can't distribute under any other license except the UDK EULA. So I can only choose that or be screwed. Or am I not understanding this correctly?

Q: What's the definition of ""release UDK code""? Is using udk code, eg extends a class from UTGame, included? Or it's only prohibit publishing UDK source code?

A: This means you cannot release your UDK application (code and content) under terms that we did not grant you. For example, you may not release your UDK application into open source or under a GPL, LGPL type license as we do not convey the rights to you to do so.

Q: ""...under a license that is not from Epic Games"" Does that mean if you do obtain license from Epic Games, (eg, the 25% royalty commercial license of UDK), you can freely use the content packaged with UDK?

A: This means you cannot release your UDK application (code and content) under terms that we did not grant you. For example, you may not release your UDK application into open source or under a GPL, LGPL type license as we do not convey the rights to you to do so.

I am not looking for employment at this time since I am still at university. But I will be done with my degree next year. So in that regard, yes employment wouldn't be bad. Making profit would of course be nice as well but I can see that there aren't many people left that stuck to UDK. And the return would pretty much have to cover at least the 99$ license cost. If I can get something out of my hard work first and then it is stolen oh well, even the biggest companies can't prevent piracy. But it would be even worse if my work is stolen and I didn't get anything back, not even that it was originally me that developed this thing. So I hope you can understand it from this point of view too, especially since nobody else seems that have achieved it (yet). And if I give away all the "company secrets" so to say and then copies pop up based on the ideas that I gave away how would you like that? If only I could be sure to at least be credited for my work, then it may already look much different. But I've seen too many post like this: "Hi, I have no idea what I'm doing but you seem to know. Can you make this game for me? I want a, b, c, d and e." And the most popular response: "Why should anyone take the time and make the game for you?" (without getting anything back, except a "Thank you" maybe).

I am very open to further discussion about this.

@UnrealEverything
Kudos! Is your work applicable to UE4 and procedural game generation in general? (Beyond Construction Scripts and in-Editor Procedural utilities in UE4 at present)

If the release of 'No Man's Sky' next year is a game changer, then maybe just maybe this type of functionality will show up on Epic's radar. Sadly at the moment it isn't a priority. Procedural helps level the playing field between smaller teams and Triple-AAA studios, because doing everything statically all of the time just takes too long with a small team...

Yes I don't see why not. Especially with C++ power at your hands. It might even be possible entirely with blueprint but could get out of hand with all the necessary wiring you'd have to do
I haven't implemented any examples where the dynamic terrain is procedurally generated but everything needed for that is there. You'd essentially only need to create a new class that extends one of my terrain system classes and implement the terrain generation algorithm there.

sadly the days seem over, when threads like this served as inspiration for others, but it wasn't always like this. there used to be plenty of examples where it would inspire others and these others would ask for the info, then the OP would explain the rough general method in a pretty non-technical language. in fact my blog has quite a few posts like this

but like you suggest, posts like this nowadays feel like showing off and only evoke "give me, I want" replies. this is especially obvious in the UE4 forums

curious thing, art forums don't suffer from this. people look for critiques and comments and the community helps (or the post goes unnoticed), but all the community gets in return for their help is eyecandy and inspiration

So did I do anything wrong? I was quite happy with isathar's question earlier, specifically about the collision.
Something tells me that kind of attitude is caused by the competition between joung up-and-coming developers that are looking for work. Just my opinion on that.

So what is finally the key on this kind of dynamic terrain wich, is using for what i can see" tessallation "? nope?, you need to create a kind of weird material and change it's parameters in runtime then assign it to the landscape ?

Sorry for my direct, " post of " But this feature it's just awsome, and a feature that i always admired and i did not think it was possible in UDK just unrealscript, it's not the thing that i want to use it, " wich ofc i would like to make use of it in some projects " but, all the knowladge and craziness that it's behind of it.
Well atleast give some reasonable points, on how you did it, this way i would try it myself, and i would be more satisfied than even copy pasting and understanding :P.
Key point, " is this all modifying a MIC, wich is assigned on the landscape material ? And then changes are applied due to the change of the MIC params?

To answer them both. No, tessellation is not 100% necessary but it can be used. The system works even when the TessellationMultiplier is set to a very small value in the material. Doing so will not create new geometry then.
What you do need is a material similar to that in the realtime deformation gem [UDN]DevelopmentKitGemsRealTimeDeformation[/UDN] more complex for reasons though. But instead of using SkeletalMeshes and HitMask, the visible geometry consists of StaticMeshes and the Heightmap is stored in ScriptedTextures and/or Texture2DDynamic. Those textures are sampled in the material and the result multiplied with the terrain's up vector to achieve the deformation.
Code-wise you need to create the terrain's visible geometry (a number of StaticMeshComponents with a StaticMesh that consist of triangulated quads), probably the easiest part. Then the collision which must be built manually for every patch that needs to collide and must be updated accordingly as explained above (4 right-angle triangles are need per patch at most to generate the collision, they aren't visible unless they are shown for debugging). And finally you'll need a way to write meaningful information to your heightmap textures and a method of generating or reading the height values from, for example a file, or by copying from the normal Terrain or Landscape.
Was that too technical? I'm still open for question like I said before.



The demo is almost ready by the way. I'll have to recreate the installer again and upload it but that should be it. I haven't figured out how to force the installed version to start in DX11/D3D11 mode though, so you'll need to manually create a shortcut and add -D3D11 and/or -DX11 .

[Neongho]

To answer them both. No, tessellation is not 100% necessary but it can be used. The system works even when the TessellationMultiplier is set to a very small value in the material. Doing so will not create new geometry then.
What you do need is a material similar to that in the realtime deformation gem DevelopmentKitGemsRealTimeDeformation more complex for reasons though. But instead of using SkeletalMeshes and HitMask, the visible geometry consists of StaticMeshes and the Heightmap is stored in ScriptedTextures and/or Texture2DDynamic. Those textures are sampled in the material and the result multiplied with the terrain's up vector to achieve the deformation.
Code-wise you need to create the terrain's visible geometry (a number of StaticMeshComponents with a StaticMesh that consist of triangulated quads), probably the easiest part. Then the collision which must be built manually for every patch that needs to collide and must be updated accordingly as explained above (4 right-angle triangles are need per patch at most to generate the collision, they aren't visible unless they are shown for debugging). And finally you'll need a way to write meaningful information to your heightmap textures and a method of generating or reading the height values from, for example a file, or by copying from the normal Terrain or Landscape.
Was that too technical? I'm still open for question like I said before.

Ill try the tessallation example, ill check out the material and ill try to figure out how im going to do this on a static mesh lol. It's worth the tries.

The demo is almost ready by the way. I'll have to recreate the installer again and upload it but that should be it. I haven't figured out how to force the installed version to start in DX11/D3D11 mode though, so you'll need to manually create a shortcut and add -D3D11 and/or -DX11 .

Perhaps you can create your own custom shortcuts through using this way to create an installer, you'll loose extra time, but ofc it makes of your build something really cool.

https://forums.epicgames.com/threads...ur-Final-Build

If you check out the final posts you'll see that there is a fix to, to a known issue with it.

the visible geometry consists of StaticMeshes and the Heightmap is stored in ScriptedTextures and/or Texture2DDynamic. Those textures are sampled in the material and the result multiplied with the terrain's up vector to achieve the deformation.
Code-wise you need to create the terrain's visible geometry (a number of StaticMeshComponents with a StaticMesh that consist of triangulated quads), probably the easiest part. Then the collision which must be built manually for every patch that needs to collide and must be updated accordingly as explained above (4 right-angle triangles are need per patch at most to generate the collision, they aren't visible unless they are shown for debugging). And finally you'll need a way to write meaningful information to your heightmap textures and a method of generating or reading the height values from, for example a file, or by copying from the normal Terrain or Landscape.
Was that too technical?

Well it doesen't sound easy i give you that... some images would help hehe.

[frankit]

@UnrealEverything...
Wow! Still an undergrad with 6 years posting on the forums?... I predict a bright future ahead...

[Chosker]

So did I do anything wrong? I was quite happy with isathar's question earlier, specifically about the collision.
Something tells me that kind of attitude is caused by the competition between joung up-and-coming developers that are looking for work. Just my opinion on that.

on the contrary. my comment is mostly geared against threads like this where the replies only are about asking for the source or the OP only shows off, but neither is the case here

the cause could be what you're saying, or it could also be that people just think "oh I want that in my game and it'd be so much easier if I don't have to do it". don't get me wrong, it's great to have a sense of community and sharing (as is the case in UE4) but it's annoying when everything that is shown by anyone is expected to come with the source (as is the case in UE4)

[frankit]

@UnrealEverything
Could your Dynamic Terrain be used to create this :-

http://www.youtube.com/watch?v=Hr2pAjbDNYU
http://www.youtube.com/watch?v=Aah4uWaqcwE
http://www.youtube.com/watch?v=jsaeF...eature=related
http://www.youtube.com/watch?v=iqsDwC_UGb4

[UnrealEverything]

Ill try the tessallation example, ill check out the material and ill try to figure out how im going to do this on a static mesh lol. It's worth the tries.



Perhaps you can create your own custom shortcuts through using this way to create an installer, you'll loose extra time, but ofc it makes of your build something really cool.

https://forums.epicgames.com/threads...ur-Final-Build

If you check out the final posts you'll see that there is a fix to, to a known issue with it.



Well it doesen't sound easy i give you that... some images would help hehe.

Thanks but I don't really want to create a custom installer at this point. So you'll have to create your own shortcut with the commandline arguments.

I don't see that a few images would help.

@UnrealEverything...
Wow! Still an undergrad with 6 years posting on the forums?... I predict a bright future ahead...

Well I joined around the UT3 release but wasn't active at all the first two years or so. And I do have a bachelor's degree (since earlier this year) but decided to continue with a master's degree.

on the contrary. my comment is mostly geared against threads like this where the replies only are about asking for the source or the OP only shows off, but neither is the case here

the cause could be what you're saying, or it could also be that people just think "oh I want that in my game and it'd be so much easier if I don't have to do it". don't get me wrong, it's great to have a sense of community and sharing (as is the case in UE4) but it's annoying when everything that is shown by anyone is expected to come with the source (as is the case in UE4)

Very well. I see what you mean with UE4.

@UnrealEverything
Could your Dynamic Terrain be used to create this :-

http://www.youtube.com/watch?v=Hr2pAjbDNYU
http://www.youtube.com/watch?v=Aah4uWaqcwE
http://www.youtube.com/watch?v=jsaeF...eature=related
http://www.youtube.com/watch?v=iqsDwC_UGb4

Yup, I don't see why not (in theory) although I see a couple of hurdles ahead. The hardest parts would be to get around the UV layout of a sphere and to make the up vector not global for the entire terrain as is the case for a flat terrain. Also you'd need a sufficiently detailed heightmap to provide enough variation. This could get tricky as well especially given how close you can get to the planets in the videos. And in order to have reasonable performance you'd have to look into heavy LODing. E.g. dynamic terrain only kicks in when you're getting this close to a sphere. Similar to what is observable in the videos.
Why do you need it to be dynamic though? Would it not be enough if the planets heightmaps are imported as normal textures in the editor first? Or do you want the heightmap to change later on? I can see why if this goes back to your procedural question earlier.


The demo is almost ready. I delayed it on purpose to get another map in to demonstrate a procedural heightmap generation algorithm in action. I chose a simple diamond-square approach. I shall upload it later today.

[UnrealEverything]

There you go. Download link for the demo: Dynamic Terrain Demo

[frankit]

Cheers Christian will check out the demo this week!

Why do you need it to be dynamic though? Would it not be enough if the planets heightmaps are imported as normal textures in the editor first? Or do you want the heightmap to change later on? I can see why if this goes back to your procedural question earlier.

Dynamic is wishlist, I'd happily settle for 'static' rendering of universe -> atmosphere -> planet surface...

[Neongho]

You are a Unreal Hero Unreal everything, make this with only Uscript and no open source at all, too bad there's many ignorants out there that couldn't really appreciate such a feature in Ue3, well im proud to be NOT one of em : ).

[Neongho]

mmmh there's a couple of bugs so far, if they can be called bugs ofc.

1 - the collision gets updated after 5 mins or so, is that normal ?

2 - It takes a lot of time for the build to finish the whole terrain. Is it normal to ?

[UnrealEverything]

mmmh there's a couple of bugs so far, if they can be called bugs ofc.

1 - the collision gets updated after 5 mins or so, is that normal ?

2 - It takes a lot of time for the build to finish the whole terrain. Is it normal to ?

1: This is kind of directly related to your second question. On maps that have the dynamic terrain constructed from terrain and/or landscape, the collision of terrain/landscape is still needed to determine the heightmap (via tracing the vertices). Only after the entire dynamic terrain is done building, the collision of terrain/landscape is disabled and the dynamic one will fully take over. If the terrain/landscape wouldn't collide from the start, it would also not be traceable.

2: Depends on which map you're on. The diamond-square example finishes in a couple of seconds (256x256 patches). I guess you're either testing the landscape or WakeIsland. Those take alot longer yes. I've limited the number of iterations per tick to 20. And the terrain is 1024x1024 patches in size so it takes approximately 50000 ticks to complete. Given 60 ticks a second around 15 minutes. You only need to go through this process once though because the terrain saves its progress at certain points. You could with a custom installer ship the presaved dynamic terrain files as well. Your customers wouldn't have to go through this process then. This limitation is necessary because of the 10000000 jumps that the engine allows you to do per tick. Otherwise the program would essentially crash immediately because it would try to calculate whatever in the first tick and then hit that jump limitation.

[theflamingskunk]

Very impressive! Its always nice to see people pushing the borders of whats possible within the constraints of UDK.

Minor word of advice: if you intend to demo this on some kind of portfolio (which I highly recommend you do), I recommend you make a concise (Probably < 3 minutes), video quickly showcasing all of the features of the system. That way people can quickly glance at it and see whats going on.