It would be great if it could work over the internet, but that’s too complicated for me.
When the time comes, I will have to seek help from more experienced people to make it replicate properly.
At this early stage I won’t even bother about it and focus on implementing the Sculpt features.
Added a SculptComponent that handles all player input and sends update request to terrain.
ProceduralMeshComponent can be used instead of RuntimeMeshComponent.
Other minor changes.
What surprised me most is, that the ProceduralMesh is actually **faster **than the RuntimeMesh. In the beginning you can see the performance of the RMC. (at about 2:00 i change it to PMC)
Besides that, I started to use “CalculateTangentsForMesh” to generate the Vertex Normals. Because that function is so demanding, I only execute it once when releasing the Mouse button.
I will have to replace that sooner or later, because I don’t like how that messes with my normals while sculpting.
That CalculateTangentsForMesh function also does much more than I need. It generates tangents & normals for a whole section instead for only the affected vertices.
All I need are the normals around the brush.
I will either:
make my own method to calculate normals
use line trace HitResult.Normal (I use this when generating the terrain. Works surprisingly well but has it’s flaws)
wait for v2.0 of RuntimeMeshComponent. The author plans to release his own method that might be better.
Since I started this project, I noticed that my harddrive space was getting fuller for no reason.
I figured that the problem was ue4s “DerivedDataCache” which was getting bigger every time “CreateMeshSection” and “UpdateMeshSection” executes.
I had to delete 67gb yesterday and there are again 5gb in there.
It is intersting, that the “UpdateMeshSection” function of the PMC does not affect the size while the RMC does. No idea what’s going on.
Using blueprints helped me alot to understand c++ and programming in general. Once I understood the basics, it was the same as doing things in BP… only less messy.
I still have alot to learn about c++ outside unreal…
Started Porting whole Project to Blueprint (50% done)
About Painting Layers:
There are currently 4 paintable layers (+1 background layer) but I think by splitting the RGBA channels I could make 8 or even 16 paintable layers (+1).
16 layers probably won’t work because of the texture sampler limit of the material…
Mockup setup of what I mean by splitting rgba channels: [spoiler]
About Blueprint Port:
I spent about 10h porting this project to blueprint.
The terrain generation part is almost completed, still have to add all the sculpt functions and some section update stuff.
about near future plans:
I am thinking about making the generation more procedural. Currently every vertex location is stored inside a TArray. This makes the initial generation very slow and costs alot of memory.
As long as the vertices haven’t been updated, I don’t have to store them. I could get the height by noise and only store the vertices that I modified by sculpting.
That way the terrain itself could be infinite…
Hi just found this thread, great work!
In my game I’m planning to use explosives to deform terrain (just a simple downward excavation then fill the hole with a detailed static mesh crater). Would this be possible with your system?
Regards
Slinky
With the current Version, you could add the sculpt component to the explosive and execute a sculpt request on explosion with desired settings.
I think I can add a trigger OnRadialDamage. That way it could work automatically without you having to setup anything. (Exept your detailed mesh)
Wow that would be superb! The sculpt request just needs to be a simple zero falloff puck shaped hole. I’ll check out your system when i get a chance tomorrow.
Regards
Slinky
I tried to trigger on radial damage from bp and c++, but it seems that it does not work with ProceduralMesh- and RuntimeMeshComponents.
It might be my fault, I usually don’t use ue4s damage system…
To make craters you would have to use one of the two functions in the red comment bubble below. both do pretty much the same.
[spoiler]
In your case, I would prefer the one that bypasses the SculptComponent.
Just when your explosive is about to go BOOM, cast to the TerrainSection and execute the function. (radius, strength and falloff can be set in the SculptSettings struct)
I started researching clipmaps some time ago, but decided not to use them because it seemed harder to implement then equally sized chunks of terrain. But I was wrong.
Geometry clipmaps allow me to generate much bigger terrains. Hundreds of km in size.
My current testing implementation is a little different from the article. I don’t use the footprint approach like in the image. A single Clipmap is either created with or without hole as a single proc mesh section.
The reason for this is, that I don’t see the benefit in ue4 of having 15 mesh sections (12x block + 4 ring fix ups) when it can be done in a single section + Interior trim.
Also the collision is all wrong with multiple sections when using the procedural mesh (runtime mesh works fine)
The Clipmaps can go beyond the “actual terrain” that is stored.
You can define a Terrain size of 2048x2048, 4096x4096 or whatever you need. Only those vertex data will be stored.
If you wander outside, the clipmaps will use a noise function to get the terrain height. Also the noise has to be calculated…
if I don’t calculate normals for each vertex per update, I can have a solid framerate with 12 Clipmaps, each up to 128 verts per side ( = 262km terrain visible with gridsize 1m).
If I do calculate the normals…well, it doesn’t look that good, but I’m working on it.
I still have to:
add the “Interior Trim” to cover the seams
reuse Vertex data and only recalculate at seam when moving (This will bring the biggest performance boost)
code out vertex T-Junctions at seam
I will try to post my progress every other week or so.
