something exciting coming into unity look into the doc
“Asynchronous readbacks of GPU data. Asynchronous compute.”
1 Like
Very interesting, nice find! Guess it’ll be quite a while until that arrives in a final (or even beta), as its not yet on their 5.5 roadmap (at least not the full thing).
But yeah, even more due to this I might reimplement the render strategy for testing purposes once again, based on a read-back (synchronuously for the moment) of the GPU data before rendering to create a correct mesh and bounding box instead of replacing vertices in the shaders and not having the bounds on CPU.
Have to finish my current implementations first before moving back to that topic.
a) a dynamic galaxy skybox (I:BS’s background motivated me to try that to be honest 
) you can fly through which is ~half done. It gets more dense to the core already using Box-Müller ( https://en.wikipedia.org/wiki/Box–Muller_transform ). There are still a few things to be done: The swirl effect is to be applied, and the random function is to be replaced with a pseudo-random one. But its a cool method, could be usefull for asteroid fields too!
b) Automatic spaceship controls based on physics using thrusters which can generically be applied to the ship. The controls should be in charge for speed, velocity direction and ship rotation at the same time. A totally different but interesting and fun topic. Not that simple as I thought first, especially when it should dynamically (which it doesnt yet) check the available thrusters attached at startup so that the script works for different kind of ship designs.
@Akenre your final normalmap looks good. Have you checked the lighting of your normalmaps when applied to a sphere? I think the question which normalmap works depends on how you apply and render your sphere in the shader.
Primarily i intend to use the normal information gained from the difference algorithm (that i just visualized with that normal map texture) for setting the world-space vertex normals of the patch(es) to use in the pixel shader with the light direction vector. In my understanding, only then can the 3d engine render the light correctly. There might be a way though with using normal maps and then transforming the camera into the patch space in the pixel/fragment shader, which i suspect most people do.
To calculate the world normals i must rotate the local patch normal vectors to be oriented according to the patch location on the sphere.
I have come up with a quaternion rotation to do that, but unfortunately, the normals end up wrong.
So i’d be interested to know how you are getting the normals right?
Psst your planet needs clear-a-sill. (spelling) (zit lotion)
So I went back to my planet generator this weekend, wanted to fiddle with cloud generation a bit. Decided to make a new Unity project and clean everything up, ended up converting my current ‘loaned’ atmospheric scattering to pure ray traced one. That took about two days and the visual difference is negligible, however the rare seam problem got resolved and I moved away from face specific code for some of the faces that was placeholder. Then I moved over to volumetric rendering of clouds and I have a functional build, so damn happy came here to post it…
As usual learned a lot.
4 Likes
Im working again on the Planet, now i implemented MultiThreading!
I can rush over the Planet Surface and there is no stuttering and no lagging - sorry the Planet is red because i create a new Project with only the bare necessities to implement Threading.
In this implementation i create following Maps (GPU):
35x35 Heightmap
512x512 Heightmap for the NormalMap
512x512 Normalmap
Every Chunk/Patch creates this 3 Maps.
4 Likes
Looks nice, runs very smooth and quick for this Heightmap/Normalmap resolution and the fast camera movement! Well done!
What scale has that planet, and how deep do you traverse into your quadtree (I asume you use a quadtree) in that video?
Hey, thx for response!
The scale is Earth-Like, so the radius is ~6000km ( unitcube * 6000)
Im currently divide the QuadTree 20times - i can go deeper, but when i do this the normalmap have artefacts…
I have a question: How outerra or Battlescape do their Texturing??? only with Colors looks not realistic 
Wow if that is the case then you pretty much overcome meter resolution with 20 depth and 512x512 textures (0,02 meter per texture-pixel at the 20th division if I calculated right). Very good!
One Patch have 35x35 vertices - the distance in a unitPlane from Vertex to Vertex is = 0,02857…
This Plane on earth size the distance from Vertex to Vertex is: 171,42
RootNode: 171,42
1st level: 85,71
2nd level: 42,85
…
…
20th level : 8,57 from vertex to vertex
so one patch with level 20 has a width/height of 300km…
IDK if my calculation is right or complete nonsense because the curvature of the Planet…
Hmm… I think if you are able to reach level 20 the resolution must be way higher?
Given the earth has an equator of 40.000 km, with a quadsphere this equator is split into four segements (=patches), so each patch at level 0 has a width of 10.000km as part of the equator. Now if we start splitting a plane, this increases significantly. At level 1 each patch fills a width of 5.000km from edge to edge, at level 2 each fills 2.500km, level 3 each fills 1.250km, at level 4 each fills 625, and already at level 5 each fills 312,5km from edge to edge.
Of course I’ve completely ignored the curvature of the quadsphere for the moment, but the resolution at level 20 should still be similar to the above if I am not wrong? Am I overseeing something?
Wow, thank you for the effort, sounds plausible!
so that means i have a resolution of ~10 meters.?!
Man, thats crazy.
Sorry im not good in Math, but i have a iron will. So i dont really know what im doing, what im only do is
I really like to know which resolution Infinity battlescape have…
while(true)
{
-change something
-hit F5 in Visual Studio
- look
}
I tested now with LOD level 24 - heavy GPU work, but it works!
Here are the Maps that im generating for each LOD level:
// HeightMap 35x35
node.heightMap = Terrain.CreateHeightMap.Execute(node.extents, Globals.nodeSize, node.level, node.Side, false);
// HeightMap for NormalMap 256x256
node.heightMap2 = Terrain.CreateHeightMap.Execute(node.extents, 256, node.level, node.Side, true);
// NormalMap 256x256
node.normalMap = Terrain.CreateNormalMap.Execute(node.heightMap2, node.extents, node.level, 256);
// Colormap for normalMap 256x256
node.colorMap = Terrain.CreateColorMap.Execute(node.normalMap, node.heightMap2, node.extents, node.level, 256);
P.S: hello from the mountain 
Argh, i cant find good Noise values for mountains and Continents
3 Likes
Who is working on a Planet, and how is the status.
pls post some Screens like i do,I’m curious how you do!
3 Likes
Hi @montify , your pleanet looks beautiful! Very well done! I like the atmospheric scattering effect, it looks beautiful. Maybe a bit too bright at close surface. But nice, it brings the look of procedurally generated surfaces to another level.
No eye candy currently because I went away from the planet problem, probably until Unity3D 5.6 in March 2017 to investigate into the new Unity features, especially
5.5
Exposed Meshes and ComputeBuffers to native code plugins
- Mesh.GetNativeIndexBufferPtr
- Mesh.GetNativeVertexBufferPtr
- ComputeBuffer.GetNativeBufferPtr
5.6
GPU Instancing Improvements - Procedural mode: supply instance data from a custom data source
- DrawMeshInstancedIndirect: supply draw arguments from a GPU resource
I have that feeling it has no sense to work on the planetary renderer currently while those extensions are still in the works. The Unity guys seem to heaviliy optimize Unity’s render strategy currently, so I guess the wait is worth it.
Instead I went back to the very basic, very very basic structure of my application. It concerned me that my current procedural universe version created and placed planets simply based on Simplex Noise. Although I tried to keep 1:1 scale and reasonable distances between e.g. planets and suns, it wasnt realistic. Suns and planets pseudorandomly placed here and there.
Also I didnt like the way I streamed in objects, meaning how I instanciated and destroyed objects. Lastly I had the feeling there is still big room for design and performance improvement implementing the Scaled Space approach (originally from KSP) to render close and far away objects at once. Performance counts and is horribly important here, as I want to render a lot of visible objects, and I want to allow travvel from slow to extremly quicky (+1000x c). So objects needs to be referenced to often and very quickly. I organize the objects ins hastables and try to avoid any costly Unity call whereever possible (e.g. GetComponent). In favour for a new ScaledSpace approach I organize all my objects in the hastables and references, completely avoiding Unity’s parenting hirarchy for the large celestial bodies. I hope this works out.
Also certain checks for extremly far away objects are now less often done than for close ones. All that stuff.
So I currently reorganize and redesign lots of stuff. My current approach for instanciating objects is that each object (e.g. a sun or a planet) has a specific “Controller”-class attached that, besides other stuff, can instanciate further objects via “Factory”-classes. Typically depending on the camera distance.
(not yet decided) -> creates Galaxy
Galaxy -> creates (not yet decided)
(not yet decided) -> creates SolarSystem
SolarSystem -> creates Sun
SolarSystem -> creates Planet(s)
Planet -> creates PlanetaryRing
Planet -> creates Moon(s)
AsteroidField -> creates Asteroid(s)
Asteroid -> creates AsteroidDust
This allows better LODing and keeping the need for resources low, the scene basically manages itself. If you are far away from a solarsystem, there is no sense in having a planet, nor a planet checking if it should render a moon. However I havent yet started profiling all the above.
Well besides the organization I implemented the SolarSystem controller which now places the sun and planets in a correct scale. Furthermore I added a lot of astronomical information to each object. The sun has a certain mass, luminocity, temperature etc. The planet has mass, orbital peroid based on Keplers law, temperature (based on physical calculations that consider the planet parameters, albedo, distance to sun, sun parameters etc.), habitability scoring etc. Some work went into seaching the web for any interesting physical / astronomic / mathematical constant I could gather in a single “GlobalConstants”-Class ;-).
The sun has an adequate 1:1 scale and the planets are scaled and positioned in the orbit also realistically (technically, in Unity depending on the Space (LocalSpace, ScaledSpace etc.) to workaround the float problem). I’ve warned you, no eyecandy this time.
While checking how to place planets orbiting the sun I stumbled across the Titus Bode Law, which is a very interesting read. https://en.wikipedia.org/wiki/Titius–Bode_law
The formula is super super simple but helps to place planets right in a solarsystem similar to ours. There are lots of discussions about that formula that is not based on any physical law or cause, nonetheless it is quite acurate in our solarsystem and, interesting too, at further solarsystems which were analysed to disprove the theory.
While working on this you stumble about many questions fun thinking about.
- How small or large can a sun be (until it would end up to something else)?
- How small or large can a solid planet be?
- Are there “lonely” dark planets outside a solar system without an object they orbit (hopefully not, this does not fit to my instancing strategy
)? - Which planet types can have planetary rings?
- How are asteroid fields spreaded and organized? E.g. how could you handle the Kuiper Belt which is a small circumstellar disc surrounding the sun? I am right now thinking about a “AsteroidBelt” instance that regularly checks the radius and angle of the player position compared to the sun, and starts the instanciate asteroids when the player is within a certain threshhold. I guess the asteroid belt or the density of the asteroids within is not visible, as the area is still way to large, so there shouldnt be a need to render anything ring-like.
But well this is my planet stuff currently. Not even as beautiful as yours, only too much tl;dr and no screenies.
2 Likes
Hello all again! Merry Christmas!
My project since last update was heavily modified. A lot of stuff!
Rings, shadows, eclipses, flares, core fixes, plantshine, starfield and etc.
Anyway i have problems with spherical normals…
@JoergZdarsky, you can use something like that:
UNIVERSE_MANAGER[GOD_MANAGER] -> creates Galaxy
Galaxy -> CLUSTER
CLUSTER -> creates SolarSystem
…
etc.
Where cluster is cube area. Like a chunk in minecraft world. You know.
It would be easier to manage all stuff via hashes and getters.
IDK, on my mind.
@montify, here you go!
And here you can see bleeding-edge version launched under Linux and OpenGL. And it works! 100%.
4 Likes
Remember that stars come in all sizes right down to class M. Remember too, that most stars are class M. The little guys. And if the general pattern continues, then rogue planets are by far the most common objects in the galaxy. They are objects that never got as big as a class M star and we just can’t see them from very far away. Then you get down into Jupiter-sized objects which could very likely have moons. A mini-planetary system, if you will. Keep going smaller until you’re down to comet-sized objects that are formed of just whatever happened to be around. The numbers of those things must be mind boggling.
From the standpoint of visiting these systems, I’d say to stick with planetary systems around stars. They’re the most complex and interesting, I would imagine.
2 Likes
@zameran wow nice Screens, im so happy that others working on the same kind of Project!
thx for your comment, yeah to bright… but i play a lot with the values - all aspect of the Planet is on heavy developement!
Unity:
Maybe you don’t use the GameObject class ( too much overhead) instead you should use the Low-Level commands ( GL.Draw,…).
Honestly, i dont implemented any kind of culling that means no Boundingbox, nothing. only the Quadtree and it runs smooth!
My first goal is to render one Planet with all kind of aspect’s a Planet should have, second Asteroids to travel from the Planet to the Asteroid and back or so ^^
“How small or large can a sun be (until it would end up to something else)?”
it can be any size you want, because a Vector have no measure when i decide one Vector unit is 1km and i make the planet’s radius 6000units it is earth sized.
Do you use “Render relative to the GPU” for the float precision?
im interested in the time i invest to learn C#/XNA/DirectX and Planet specific content, since 2012. I guess more than 2000 hours in the past, sometimes i develop 18hourse a day…
And im sure i pressed F5 in Visual Studio more than a billion time lol
So now i hope i have fixed the lightning bug, here so screens:
omg, i see it now, the .png compression is so bad
Keep this thread alive! ;9
P.S.: Anybody have an Idea how i can handle SimplexNoise, i cant create Mountains and so 
Do you guys use the Simplex noise Algo on the GPU?
Next Step: better Texturing, anybody have an Idea how Inovae or Outerra do this?
3 Likes
@montify:
Glad to see! Thanks.
Can you explain all stuff around your normalmapping?
Looks your calculation method is the same to me, but i don’t know how to ‘spherefy’ my normal vercors…
Ho do you do it?
the answer is i dont spherify the normals, i only use the Tangent-Space…
I thinking about that, but when i have a normal GameObject like a Ball or so, technical it’s the same, a sphere. But you dont have to spherify the Ball’s normal map?
This is the code to transfer the normalmap into tangent space:
float3 normalMap = tex2D(NormalMapSampler, input.UV).rgb;
normalMap = normalize(mul(2.0f *normalMap - 1.0f, input.WorldToTangentSpace));
How do you this? and screenshot pls! 
One moment!
For the tangent i need the VertexNormal. So i create the Sphere, add the height, and than i create the Vertex Normals! ( all on the CPU) im not sure if this makes the different?
@montify, so.
I calculate normalmap from height data with sobel filter. [Having another methods too…]
The result is:
After that i pass this texture to Quad shader, where simply apply it.
As result i have Quad-Space normalmap texture.
And with light…
Pseudo code: [Simplified Lambertian Illumination Model]
float theta = dot(normal, sunDirection);
float3 groundColor = blablablaCOLOR * theta;