So I have a question.
How big are you planning on these planets on being?
Just curious 
No idea, will have to see how the engine copes. I would say that ultimately I am aiming to build a system similar to No Man’s Sky. Which means :
- The planets are actually really tiny compared to real planets
- When you enter the atmosphere, the spherical world (CGWorld) is swapped out for a flat tile-based one (CGTerrainManager), hidden with some visual . With the noise coordinates used on CGTerrain Manager being mapped onto the sperical world it should look pretty seamless, and circle round on itself ok.
Really depends on perforamnce though. I’m still using the RMC/PMC normal+tangent calculation which is achingly slow and on the game thread so I don’t have a good idea yet.
You’re using the CGTerrainManager right? Well you can pack this information into one of the vertexcolour channels, although it may not be that easy to get at on the game thread.
Alternatively, considering some mathematical techniques :
Building Worlds Using Math(s) Around the 33:00 mark Sean Murray talks about calculating the analytical derivative which in very basic terms gives you some information about the slope on a given point.
To use the plugin in it’s current state, can I add noise through blueprints, or is the noise added by code at this point?
Blueprints, tutorial video I posted covers it.
I was probably unclear. :o
Does that go for the CG World part as well? I’m pulling the plugin from the CG_World branch.
And that looks amazing!
Yep, uses the same UnrealFastNoise modular generation system.
That image is using a few different blended generators and masks + domain warping.
When I make a CG World actor, I’m unable to get the Set Up Terrain node to compile. Cause it needs a target.
I might be totally blond here and miss something tho.
EDIT: No offence to blond people, just a figure of speech. :o
It’s called SetupWorld on CGWorld :>
Nope, no SetupWorld node.
EDIT: I downloaded the plugin again and now there is a Setup World node. I was really sure I had downloaded right after you had updated the changes.
Anywho, time to make some planets! 
@mid_gen
Is there any plans of making the CGWorldFaces that’s created to be a child of the CGWorld that creates them?
Just to clarify, I was hoping to do this in the game thread. Slopes aren’t super-important, just as long as I can return the (Z)-height of an (XY)-point from a CGTile to make it easy to place foliage on a tile’s surface.
An example of such a function would be: auto fSurfaceZ = myCGTile->GetHeightAtPoint(x, y); myTree->SetActorLocation(x, y, fSurfaceZ);
Is height information stored anywhere in your code, perhaps on a per-tile basis? Because then it should be as simple as exposing this information to other classes/blueprints.
Or maybe to coincide with what I’m doing, whilst keeping it thread-safe, perhaps a multicast delegate could be triggered once a tile’s height information is generated, passing out a copy of the data?
That way, the information can be discarded for those who don’t care about it, whereas others can store this info however they wish.
I suppose if raycasts (ie, UWorld::LineTraceSingleByChannel) are more efficient than any other solution, then sadly, I’ll have to go with that.
But I’ve read that they get expensive rather quickly, which is why I figured it was worth asking you if a better alternative was potentially present.
The heightmap and mesh data is managed by a pool in CGTerrainManager so once it’s been used to render the terrain, it’ll get re-used by another job.
If you want to place things accurately on the surface of the terrain though, you’ll need to raycast. You can’t just use the noise generator to get the surface height because the actual position of the mesh at that point will be different everywhere but right on a vertex. The advantage of the ray cast is that you get the normal.
This was done by raycasting :
Will be yes, have lots of tidying up to do still.
Sweet. I know it’s early in the development, and it’s really fun to follow along and see it evolve even more.
Does the CGWorld in this image have a little bit more than 4 subdivisions? Or how did you generate such a detailed planet?
Any plans for 4.16 support?
If you pull from the branch again I’ve disabled the mega slow normal/tangent calculation. With that image I think I was running 21 subdivs with a 7 subdiv limit.
should be working fine with 4.16 with the appropriate RMC update.
That’s really nice!
And I can confirm that this works in 4.16.1 as well. I’ve pulled the CG-World branch tho. But as far as I know, also works in 4.16.1.