i use sobel filter too!
Use + instead *…
And i think the normals are to strong, have you implemented a value to control the normals?
This is my lightning calculation:
float DiffuseIntensity = 0.55f;
float3 DiffuseColor = tex2D(ColorMapSampler, input.UV).rgb;
DiffuseColor += dot(normalMap, normalize(-v3LightPos));
float3 f = saturate(DiffuseColor * DiffuseIntensity);
And my normal look:
Why should i use + instead of * ? 
I have strong formula for my atmospheric scattering:
float3 groundColor = 1.5 * RGB2Reflectance(terrainColor).rgb * (sunL * max(cTheta, 0) + skyE) / M_PI;
Hm. Your sobel is much different, you know? 
Yeah the normals little bit off 
Do you multiply the normals with the World Matrix?
How can i calculate it?
Now i have some sort of it - RotationMatrix.
middleNormalized - Quad Center On Sphere.
I dont, i have a Identity Matrix as WorldMatrix, because i add a Vector to my flatPlane
so
Vector3.Up + flatPlane = upper side
Vector3.Forward + flatPlane = Forward side of the cube.
But before i use a Matrix for the rotation - and it work the same way as now. maybe your sobel filter is wrong?
No. My normalmap calculations is OK anyway.
Don’t look at crazy slope 
Testing purpose.
[].noise is float value of Noise.
Well yes maybe a Cluster could indeed be the Factory of a SolarSystem, however a Cluster in term of a StarCluster. If I got you right and you think of a cluster like the uniform chunks in Minecraft, then no this wouldn’t be what I intend, this is more or less what I did before. But I dont find this realistical enough, as the resulting structure would be too equal even when making heavy use of noise algorithms.
Because structure “on top” of a solar system is more complicated and complex, compared to Minecraft where there is no higher hierarchy across chunks. In minecraft each chunk is more or less equal to its next ones, there is no higher structure where chunks drastically change over time except for biomes, but even those and the overall landscape is very repetitive and equally spreaded.
For the structure hierarchically above the solarsystem you must consider that there a certain structure withing the galaxy, empty areas, and spiral arms that hold al kind of structures (gas, stars and star clusters etc). Simply didiving the world into chunks which creates celestial bodies using a seed will lead to repetiveness, but not to those galaxy structures.
There is a very cool article from Martin Evans how to generate a galaxy kind of structure. He also describes a kind of factory approach partially, and this is what I am thinking of. So to split the galaxy into a core and arm areas, acting as a Factory for Billboards or voxels which could subdivide until a reasonable resolution is reached (or maybe using an octree?) to create starclusters.
But well how knows, thats all pure theory I havent made my mind yet, and I need to get the basic setup for a solarsystem running well combined with a new approach for the scaled spaces first to see if it works at all.
http://martindevans.me/game-development/2016/01/14/Procedural-Generation-For-Dummies-Galaxies/
For the planet planes I didavoid that too, I agree a GameObject for each plane element is (unfortunately) too much overhead, and I also created the plane directly on the GPU. I might change that eventually once asynchronous callback of GPU data to CPU is available. However at least partially I think it might make sense to temporary create a GameObject continuously at the closest plane for collision detected so that you cannot move through the plane.
But this would require to have the data at the CPU.
For the universe structure I need GameObjects to attach the Factory classes on, in order to instanciate or destroy objects.
No, I mean in reality, not technically . There should be a certain minimum and maximum mass where a sun is more unlikely to form itself and keep stable but end up in something else. Probably something around 0.x up to ~2xx times our sun mass. I think the Eddington limited the possible sun mass by around 250 suns until they would get unstable.
For the float precision problem in general I use multiple tricks to recreate solarsystems or higher sizes. “Floating origin” first of all being the most important technique to stream in objects and create a more or less infinite area of same precision (or better, keep the precision around the camera). “Scaled spaces” to render close and very distant objects at the same time. E.g. a sun in the very far background slowly approaching the player is currently, besides LODing, ~4 times re-scaled and re-positioned within different layers until it reaches a 1unit :1meter scale. And then the “Reference frame velocity” for very quick movement. Works pretty well, KSP invented a lot of these ideas, but I am trying to enhance them to realize more than a single solarsystem. Efficently handling of the above techniques and creation of objects and stream them into the scene is crucial, if you try to handle everything at once, large and small, you pretty quick get stuck in performance drops. That why I move to the Factory approach and hierarchy of objects now to see if it helps.
For the creation of a planet I still stick to the GPU ComputeShader approach @NavyFish invented. But as mentioned, I wont touch that again until 5.6 or later
Interesting, thank you very much for pointing into that direction of the Rogue Planets. Havent though those would be that likely. Well in that case I would have to instantiate them differently, or handle them as a star or mini planetary system of its own, so spawn them similar to a star or solar system.
From a gameplay and visit point of view yes maybe solar systems are more interesting. However I find these rogue planets cool too. I wonder if there would be even enough light around to allow a human see them from a closer distance?
But well, something for the backlog then
So, i try to texture my Planet.
Nothing special, no Color, but i start to implemented Detail Texturing. So when you close to the Ground a very High detail Texture appears ( i used this Texture from Outerra - only for Testing!)
So i need to improve this technique maybe with a grayscale texture, because it is a little bit of color different.
But this is how Outerra do their nice Texture
Sorry the Video have a ugly qualy, im not a professional. but look closley at the ground.
Here a Screen - shit png compression.
@joergZdarsky ah okay thats another fact !
Kann das sein das du Deutscher bist?
lg
Breaking News
First man landed on the Planet
Made a short Video of the Planet Scales, a Guy sitting on the Planetsurface with a height of 1,4m vs. earth sized Planet
Enough space for one man
Guys, any suggestions whats not okay with my Planet or i can improve?
EDIT: i made a better Video :))
You should do the textures next, water maybe, clouds and vegetation if you wanna do more research type work. You should also start thinking about a simple game you can make with this…
Yes better Texturing but i do lot research now.
Water, i try to implement Eric Bruneton’s Ocean. the Flat version is working but the spherical not 
Hey guys, im struggling with NormalMaps, i can produce three different normalmaps.
But which one is the correct one? Or is there a rule which one is correct?
The First picture is the 1:1 Normal map which produce the Shader.
taken from the upperSide:
When converting normals to world space you should use
mul((float3x3)unity_ObjectToWorld, normal);
key being (float3x3), normals don’t need the 4th column of the world matrix.
thx, maybe im right now!
So i do texturing now:
Argh, i need Displacement mapping, but XNA ( D3D9 ) is too old…
hm, mybe SharpDX ( D3D11 ) ?
If you are using XNA, you can convert to MonoGame without needing to change much.
thx, but with monogame you can only use Vertex and PixelShader like in XNA - so Monogame is a little bit useless
I continue to work on my own framework with SharpDX, and then i port my Planet.
So i decide to re-create my Planet with Direct3D 11 (SharpDX) to use newer technology.
First step is to look how tessellation work - so different approach as chunkedLOD.
Next Step: Create a Quadtree + Tessellation because you can only tessellate a mesh few times = not detailed enough.
Im happy to explore displacement mapping and so much more comes with D3D11 - but this take time
the lags in the Video are from OBS - without it runs smooth.
I think D3D11 can handle so much more Vertices??
@JoergZdarsky
and anyone who strives to eventually build the planets into an existing game engine later.
Did you implement the scaling-system for far away objects into unity as well?
I am wondering how you store the actual 1:1(real scale) position of the objects?
In 32-bit or 64-bit floats?
If you make the objects camera-relative to handle the range of better precision more optimally,
how do the physics & animation engines process the positions accordingly?
So if you have a vehicle moving on a planet that is on the edge of a solar system,
then its real (64-bit?) coordinates are rather large if you define (0,0,0) at the center of the system.
The physics engine would have to be still fed with 32-bit values for the rigidbody component.
Lots of questions, I did tackle a few of those topics with my implementation already, but some are still to be done, however in that case I am going to share my thoughts at least. Please note that some parts heavily depend on which basic design you choose and possibly different strategies make more sense in case you develop your own engine.
Yes. In fact I’ve been working on this topic in multiple iterations now, profiling different implementation strategies.
Currently I am in my third or fourth iteration of the scaling system. Currently I think I’ve found a good design approach I like and want to proceed with because of its structure and performance. Its based on a singleton-centric “SpaceManager”. Space is my term for a specific scale state in the sense of the size of the object itself, positioning and movement (all three aspects have to be scaled!) combined with multiple “SpaceControllers” instanced for each object that possibly could change a scale state. The singleton SpaceManager is basically something where objects registers or deregisters for a specific space, where the resizing/repositioning-code is (I dont want to spread this stuff but keep it centric somewhere is good as possible), or where some unique data is being maintained (scale definitions for each space, etc.) which should be the same for all SpaceControllers. The SpaceControllers check regularly if their object which they are applied to has to do a scale change, and communicate with the SpaceManager.
In my case I also added the ReferenceFrameVelocity handling (to allow higher velocity than the physics engine can handle) to the SpaceController. I wasnt sure if I should add that to the same class, but since the velocity also depends on the scale I was fine with it in the end.
I also did spend some time to find the best datastructure (hasmap/-table or dictionaries vs. lists vs you-name-it… ) for the performance, or check where to avoid data lookups completely and go for simple switch/case structures etc. Perfomance is crucial, as while you move through space, objects might have to change scales states quite quickly and often. For the SpaceManager I ended on hashtables for keeping references to objects that register for a space and for segments where I had to do different stuff depending on the space (e.g. apply a certain scale value) I sticked to simple switch/case code instead of more beautiful dictionary lookups because they were a lot slower than switch/case code (unless you reach a certain number of elements).
One thing I added in my last/current iteration is that the more an object is scaled down the less often over multiple frames I check if I need to change the scale or LOD of the object. A low scale means most likely the object is currently very far away and, since velocity also depends on scale, slower movement makes the need for regular updates less important. Think of driving in a car looking ahead. Close objects such as a tree move very quickly to you while the very far away objects such as a hill moves miles away moves very slowly ahead. I also apply ReferenceFrameVelocity less often to the farer objects and dont move them each frame, due to the same effect. Even though the hill moves at the same speed as the tree next to your car, you dont notice the hill movement unless it gets closer. So it makes sense to make use of that.
How to manage the various scales (which can differ enormously) and how to store the position of an object are two separate topics IMHO, you need different strategies (and do face different problems ) for both. Positioning of objects in my case is based on doubles. I store each object’s position in stacked/multiple double precision values, or to be more precise, in multiple double-based Vector3 types per object.
I’ve not added too much physics to the implementation yet, besides for the spaceship. So the following is pure theory:
In terms of gravity based physics: My strategy is to either manipulate the global gravitional direction dynamically (easy in Unity) or, which is my prefered way to go, applying forces (which consider the gravity center e.g. of a planet) to each object individually to simulate the gravitational pulling effect. This is not too complicate to add and should be more precise than just working with the global Physics gravity-value. And as I made some effect to calculate the mass of each celestial body, I could consider these values too to calculate the necessary force.
This heaviliy depends on the overall implementation strategy you choose. If you simply think in a single worldspace this becomes a problem, yes. In my case that is not a problem because of the “floating origin” approach, where the camera is always at the worldspace origin, so there is always the highest precision for positioning and physics (around the camera) available.
Of course “floating origin” comes with a price, besides the implementation effort itself (and finding the most performant strategy) and a few “harder to do” 's (e.g. collision) you have to let go the idea that worldspace defines the position of an object. That is hard to overcome. I think this is something you have to get used to at universe scales anyway, but it becomes harder with floating origin. It helped me to always compare worldspace using floating origin like a small stage (a room, which is your worldspace based on float with a camera inside) that moves through a larger space around it. Objects stream in and out into the room as they intersect the room. In that case it becomes obvious that latest at that point you also need a higher level custom coordinate system for all objects (and for your current position). Because a) float or double is not sufficient anyway, and b) you cannot use your engines worldspace coordinate system within your room (because it is not static from a higher level perspective outside the room).
PS: Dont think of it that the “room” limits what is visible. The above describes only how to think of floating origin, of course this can be combined with different scales which allows a high viewrange.
I can try to add a few sketches for that if you want, however the situation might be totally different if you choose something different than floating origin.
Based on my previous prototypes with Unity you have at least the following very very basic problems to tackle separately:
@JoergZdarsky
Thank you for the description.
Your system sounds to be in an already very elaborate state after long development time.
Sketches would be welcome.
It’s difficult to imagine how the unity engine would be able to handle that
without some engine code modification.
Not sure about Unity, but some engines physicalise objects using proxies
and move those around reflecting back on the actual objects.
And for that they use the engine-inherent linear coordinate system and for that matter
the standard float position variables/vectors of the objects.
If you are aiming for a multiplayer game, then the floating origin coordinates
that the network system of the engine serializes by default from the predestined object position variables/transform matrices might conflict with the floating origin of the other players.
Certainly quite a complex task, but maybe it can be made to work without engine mod.
