【50% OFF】⏱ Space Graphics Toolkit

Can confirm the bug was on my side. Ignore me

 

Hi,

I've a problem with the planet shader. I've added an albedo texture to all detailed textures. But the albedo is mapped around the whole planet and not to the detailed texture. detailCoord doesn't work either. Can someone help me with that?

Code (CSharp):

1. float4 detailCoord = i.detail * _DetailTilingA;
2. float3 detailTexA = UNITY_SAMPLE_TEX2D_SAMPLER(_DetailMapTexA, _SecondTex, coord) * _DetailMapStrengthA;
3. float3 detailA = UnpackScaleNormal(sample2(_DetailMapA, detailCoord, polar), texMask.r * _DetailScaleA);
4. o.Normal = BlendNormals(o.Normal, detailA);

 

So after a bit of a short "game jam" style push where I refused to go back and clean up and optimize anything, just kept pushing forward, I have a basic setup that spawns a galaxy inside of an irregular hex based map grid.

The only major 3rd party asset being used here is SGT (and Odin for inspectors because well of course).

Performance is crap right now, but I know I can improve that. Right now in this "far away" view showing hundreds/thousands of stars at once you can't see any of the fancy corona or prominence details so I need to disable those when the camera is too far away to see them. I will look into that.

The area of space is completely generated procedurally. First an irregular shape of hexagons is created to represent a sector of space. This is used internally but not normally rendered. Then for each cell in the sector we look to see if a Star should be spawned there. This takes into account an overall desired stellar density as a percentage of the sector size (min and max density) and then for each cell reduces the chance of getting a star for each neighbour that has one. If a star is to be spawned in the cell then it instantiates an SGT star prefab and then randomly generates a Main Sequence star with stellar properties that are random but appropriate to the selected type.

SGT has been great for these stars and eventually planets though I imagine procedural planets will be more work than the stars were.

To me my screenshots!

First an image of with the underlying grid shown to show what is happening. Each sector will be of varying shapes, this is just one iteration example. This is actually one of the larger ones at just under 900 cells (for these runs a sector was set to be between 100 and 1,000 cells)



And just a few random examples with SGT stars. Stellar density for each is 25 to 75% of the sector










And lastly just one quick image zooming in on that last one, but much closer where we can see how nice the SGT stars look closer up.

 

By disabling the Corona and Prominence objects when the star's size on screen is too small to see them anyway, I can go from about 12fps to about 70fps with 1,000 stars visible. Those things really suck down the performance if you have a lot of stars

 

To avoid polar distortion the detail normal maps are sampled twice (equator+poles) using the sample2 function, where the detailCoord value contains both UV sets with tiling, and the polar value contains the weight between these. If you want exact mapping then you would also have to use this same approach. If you want to use your approach with polar distortion then the detailCoord.xy value can be used and will match the equator mapping.

Good idea, 23k batches looks pretty scary

 

And that was after reducing the quality lvel of the prominence objects to 10 and 6 (planes and detail or whatever they are called) from the 40 or so they had originally. I noticed no real visual difference by reducing them but they still were slowing things down massively. The Corona as well. Turning off the Cornona alone would get me to about 50fps, and then the prominiences got me to 70fps.

 

These components implement various calculations based on the camera distance and such, so they run code in Update and don't batch. In typical space scenes you only have a few of them at most so this isn't an issue, but rendering thousands at once is certainly something I didn't consider, so it will give a performance hit.

 

If they are already doing calculations based on camera distance in update, could they be given an option to enable/disable based on camera distance automatically? That's basically what I am doing but if these are already doing that sort of calculation anyway it sounds like it could be more performant.

I'm basically doing this in update:

Code (CSharp):

1.    
2. // Diameter was previously calculated anmd stored from the MeshRendere: diameter = mr.bounds.extents.magnitude;
3.        
4. pixelSize = (diameter * Mathf.Rad2Deg * Screen.height) / (Vector3.Distance(transform.position, Camera.main.transform.position) * Camera.main.fieldOfView);
5. OptimizeDetail(pixelSize < optimizationThreshold);
6.  

And the OptimizeDetail call is enabling or disabling the Corona and Prominence objects as well as swapping out the Mesh for a low or higher res geosphere.

Code (CSharp):

1.         public void OptimizeDetail(bool optimize, bool force = false)
2.         {
3.             if (!force && (optimize == optimized)) return;
4.  
5.             optimized = optimize;
6.             var mf = renderObject.GetComponent<MeshFilter>();
7.             mf.mesh = optimize ? lowResSphere : highResSphere;
8.             corona.SetActive(!optimize);
9.             foreach (GameObject prominence in prominences)
10.             {
11.                 prominence.SetActive(!optimize);
12.             }
13.          
14.         }
15.  

 

The components themselves couldn't have this kind of ability, because then they would disable themselves and not be able to enable themselves again. Such a feature would have to be implemented using a separate component, but then it gets more complicated with multiple cameras and such, so I think it's best to let the user handle this. I could optimize them so they run less code in Update, but for now this terrain stuff has my attention

 

Duh yes. My apologies for posting late and tired and not thinking it through all the way.

 

After purchasing SGT, I've found a few problems with it right out of the box.

• On the Aurora sample scene, the UI text says it shows how to do a planet with an animated aurora. When running the scene, the aurora remains frozen and does not animate at all.
• Trying to build a solar system. I copy the star from the Star sample scene, and a planet from one of the Planet sample scenes. I add a SgtFloatingPoint component to both, and a SgtFloatingOrigin component to the star, then add a SgtFloatingOrbit component to the planet, setting its parent point to the star and its radius equal to the local Z of the planet's floating point. Upon running the scene, the planet does not orbit. Tried turning it up to 100 degrees/sec, to ensure it's not just moving too slowly for me to notice; nope, sorry. No movement.
• Looked through the code to SgtFloatingOrbit, and it appears that it requires a SgtFloatingCamera in the scene for it to work properly. So I look at some of the existing scenes, determine that SgtFloatingCamera is something you put on the main Unity camera object, add one to my scene's camera... and watch the editor immediately go down in flames with a cascade of errors in the console (including at least one Stack Overflow Exception) that locks the entire thing up to the point where I have to kill the process in Task Manager.

I'm about at my wits' end here. I paid good money for this and it appears to be completely broken. I've attached the scene file; adding it to a project that has SGT and the Sample Planets imported should allow you to reproduce the issues I'm seeing, with Unity 2019.2.2f1. (It just told me there's a new version out. Haven't tested it yet, but it doesn't feel like the sort of thing updating to a new Unity version would fix.)

Any idea what's going wrong here?

 

Thanks for the scene file. I can confirm that something is going wrong here, even in the latest version. It appears to be some kind of infinite recursion caused by the interaction between the SgtFloatingOrbit, SgtFloatingObject, and SgtFloatingPoint components. I'll try and track the issue down now.

Regarding the aurora, the animation looks to be working for me. In the examples I made the animation quite slow, because when sped up the nature of the vertex displacement can become very apparent and look immersion breaking. You can increase the SgtAurora.AnimSpeed setting to 10 or so to see it animate much faster.

 

Alright I found the issue, it's because you've added two SgtFloatingObject components to your planet.

When the SgtFloatingOrbit component updates, it changes the SgtFloatingPoint state. When this happens it calls the OnPositionChanged event, which triggers both SgtFloatingObject components to update the Transform. This works fine when the first one updates, but when the second one updates it detects the transform has moved (e.g. due to manual movement), and then it updates the SgtFloatingPoint state to include this new movement. This then causes the first SgtFloatingObject to be notified, and because the Transform has moved it updates the point again, and so on and so forth they ping pong updating each other until it crashes.

In the next version I will add the DisallowMultipleComponent attribute to this component.

I also recommend you put the SgtFloatingOrigin component in its own separate GameObject if you want to use this feature (or add it to the camera). This is supposed to represent the universal position of the camera, and adding it to your star won't make sense because as soon as you add the SgtFloatingObject component to this (to make the star enter the floating origin system), it will snap to the camera position, but you want them to be separate I imagine.

 

Hi, what is the best way to make custom mask maps for a planet biomes?

 

I designed these maps using Grand Designer, then adjusted the levels and combined multiple of them in Photoshop. This can be tedious though, especially since you're adding more layers.



In related news, I've made more progress on the terrain feature.

In the last picture I showed a hybrid CDLOD terrain system that worked well, and even supported older shader model 2 hardware. However, ultimately the mesh generation code still takes up a massive amount of time when done on the CPU like that, which can lead to bad looking terrain if you move the camera faster than the CPU can generate the geometry (not very fast). Therefore, I'm not really convinced that approach was the best, and it may not have been any improvement over the current system.

So I decided to re-rewrite the terrain code and instead implement full CDLOD to see how it would work, and here's my results so far:



Besides the detail textures, this terrain is completely procedural, and uses height based texturing for now. As you can see, it renders with even less batches, and still has crazy good performance with this high amount of rendered geometry. The best thing about this technique is that the LOD itself can update almost instantly, even you move at warp speed. In my tests I can move around the planet at low altitude and get at worst 400 FPS, at over 4 million triangles. It also lends itself well to multi-threading, which can be much more tedious with alternative approaches.

However, the biggest downside is that this technique requires more modern hardware (vertex texture fetch and instancing support is needed). Another downside is that this requires a completely new atmosphere implementation, since there is no traditional geometry to apply the atmosphere shader to. In light of these issues, and because I want SGT itself to target as many devices as possible, I will be releasing this new terrain + atmosphere feature as a separate asset. I will probably release it at an initially low price to not annoy anyone hoping to see this in the current SGT, then increase it as I add more features.

I plan to add slope and latitude based texturing next, as well as some kind of noise to make it look less uniform.

If anyone has questions or feature requests for this new terrain system then feel free to post!

 

I want that even if I have to rework all the planets again. It looks super awesome.

 

Well that's embarrassing! I wonder how that happened?

...yup, that would do it.

Thanks! Orbits work now after fixing that.

All right, thanks for the explanation. That's not clear from the documentation; it looked like what it means is that that component is some sort of anchor to mark the authoritative Origin (in the coordinate system sense) of the SgtFloatingPoint system. Would you mind updating the docs to clarify?

 

Had to look that up. It looks interesting, but how good is it at generating Earthlike planets?

For the longest time, I've been searching for something--anything!--to procedurally generate terrestrial worlds that actually look realistic. Specifically, with continents that genuinely look like continents rather than "a bunch of randomly-generated noise smeared across the surface of a sphere." I have yet to find anything even remotely good. Is Grand Designer worth looking at if that's what I want?

 

Is there any chance you could expand the feature set on your proposed new plugin to create very highly detailed unique planets from a small library of textures?

The goal for game use would be to have a small download of texture files, from which at runtime very high resolution planets are created.

I'm not looking for a solution that focuses on creation of a few high-res planet textures in the Unity editor, which would then be shipped with the game. I want to cut down on the game download size and at the same time increase the variety of high resolution planets by having them be procedurally generated within the game.

That way I can pass a seed over the network, and all players can generate the same beautiful planet.

 

Honestly I don't see the point in restricting features to older hardware. Was SGT ever marketed for use in Mobile games or anything?

 

Looks interesting but at $80 for the base application and another $60 for the ability to actually export your work I think its a pass for most indies.

 

Do you need both of them?

 

Depends on your size and budget. $140 isn't that much, and if it saves you a lot of development time, it can be a worthwhile expenditure.

Also, it looks like the base product can export work; what you need the $60 add-on for is to export super-high-res versions of it. (I think. Haven't actually used them, but that's what it looks like it says.)

 

I've managed to make a more intersting looking texturing with a second mask map.

 

Absolutely, I've added it to the to-do list. I also welcome feedback on any of the other features. The vast vast majority of users don't tell me anything, so I'm just left guessing which features people use or which need more explanation!

It can be used to make very good looking planets. I wouldn't say they really look 'real' like the Earth, but I guess it depends on your taste. Everything in SGT and the Planet Pack expansion are made using it. That said, it can sometimes be very tedious to get good results. Sometimes planets that look good at lower resolution look terrible when rendered to high res. Sometimes they look good in the editor, but look totally different when imported in Unity. Often I have to drastically post process the output to get it looking anything close to what is shown in their editor. The UI is also pretty bad, and it's easy to lose your planet data until you know exactly what each button does. If you can live with these issues and don't mind spending a lot of time finely tweaking hundreds of settings to get what you want then it's a really good tool though.

Yes, this is one of my main goals. The topology and coloring of the planet in that screenshot for example is generated at runtime. The only pre-made aspect are the detail textures, which can be low resolution. I plan to add some sort of biome system that allows for lots of different types of interesting terrain in different areas, not just 'generic rock' everywhere. I also plan to add a component that procedurally picks from a library of detail textures, as well as procedurally places biomes, so the whole planet itself can be randomized from a single seed.

Nope, but I like to support as many devices and platforms as possible. SGT (and my other assets) are used in many mobile apps, and removing support for GLES 2 would cut out a fairly significant percentage of the Android userbase. It's not an issue if I release a new asset with higher device requirements, but changing an existing feature to require this might be an issue.

Indeed, it's quite a niche tool. If you need planet maps then there aren't many alternatives though.

Looks fantastic as always!

If you have any suggestions for how texturing and especially biome texturing should work with the new terrain then I'm all ears.

Currently all texturing is (planned to be) based on altitude, latitude, and slope. This will 'automatically' paint the base sand layer (sea level and below), land (grass, dirt), rocks (steep slopes), and snow (mountain peaks and poles), but this definitely isn't enough. If the user wants a desert biome in the middle of the planet then the land textures would have to fade out in favor of the underlying sand, or perhaps a separate sand texture. This could either be painted using some kind of splat map each biome controls, or perhaps I could have some kind of 'temperature' map that alters where the sand and snow is shown. Not sure though.

 

Speaking of new terrain system ... do you really need to do a CDLOD? If you use VTF you can just "slide" a single optimized progressively sparse mesh at integer interval. If anything, having angular section (based on camera orientation) make more sense to stabilize vertex while culling efficiently, even more when you realize it can be the same mesh instantiated (vertex take care of themselves). Only spawning element need a LOD tile structure. It would be simpler than trying to dynamically adapt and tessellate. Abusing modulo (fract in shader) make terrain a breeze too.

 

This approach could work, though to prevent UV issues it would require cube maps for the height and splat data. I'll have to benchmark if modifying and uploading this is as fast as as with Texture2D. As you say, the spawning (and collider) data would still need to be done separately, as they're very well suited to cubed quad trees, whereas with CDLOD they're basically given for free. This extra cost probably isn't too bad though. Another advantage is that there would be no seam cracking possibility, and handling floating origin becomes trivial. You would also be able to use standard seamless textures with no normal seams between cube faces. I'll experiment with it! Time to re-re-rewrite the terrain

 

My main use case is building procedurally-generated solar systems. I've got most of the tools I need, but orbits are currently really annoying as I have to build everything manually out of SgtFloatingOrbit and then balance it all by hand.

What would be really great is if there were some way to take basic parameters, (mass and distance from parent SgtFloatingPoint being the main ones,) and generate a correct elliptical orbit using Kepler's laws. Does SGT have anything that can do that?

 

Awesome! May I suggest a biome type that includes inhabited planet ... at least a night lights emission type texture?

 

I've implemented the basics of the single mesh idea @neoshaman mentions:



Note: This doesn't use procedural terrain data, but that won't change the rendering performance.

As you can see, it indeed leads to even more incredible performance, with trivial handling of floating origin and LOD. Removing 'shimmering' from the terrain heights is a lot more complex than just modding the vertex positions though, but I can see how it might be implemented. The detail UV data also needs augmentation to appear consistent, but I believe that shouldn't be too difficult to achieve.

I briefly tested cubemap modification time and found it to be similar to Texture2D, so perhaps this approach is superior, I'll have to work on this a bit more to see.

Working with the floating origin system can be tedious. If you don't need it then you can always use the SgtSimpleOrbit component instead, which is the same as SgtFloatingOrbit, but for normal scenes. There's no code in there to generate realistic orbits though, because the math looks scary and I'd rather focus on the graphical aspects.

This could be added, but how would it look when you get down to the surface? My current plan is to make distant terrain features look the same up close, but just be more detailed. Emissive lights from a city might look good from a distance, but they would look terrible up close. Perhaps such details could fade out as you approach, but then it would look weird I'd imagine.

 

I hear you, but ... think about it, see if there is some sort of solution, maybe something like greebles. If nothing else, the lights would make for a decent orbital view.

I guess a lot of people want uninhabited or primitive technology planets, but I think many times in game scenarios the idea is to go to a planet that is inhabited by intelligent, technological life.

 

I think I'm an educated developer, then I read stuff like this. Shader codeing really is a dark art. Was that even English?

 

No offense to SGT but for my star systems I am using Gravity Engine to handle the Kepler side of the house, and SGT for the visuals.

 

I'm not discounting the idea, it just needs to make sense in terms of how that data is rendered both up close, and far away. I can see emissive textures being useful for radioactive rock style biomes, or some kind of magma, but for cities I don't see how it would make sense. Perhaps there could be a 'city' biome that spawns lights from a distance, and up close these get replaced with buildings or something.

 

Hi Darkcoder,

here are some suggestions I would like to see in the new asset.

• Using a water asset like AQUAS Water/River Set or Crest Ocean System LWRP to create realistic oceans on a planet.
• Spawning stones, grass or whatever with a mask map. rgb channel for objects and alpha is no spawning area.
• Another nice feature would be terrain blending between spawned objects and the terrain. If you just spawn objects like stones on the surface it looks very odd and unrealistic.
• Spawning a single object at a certain place. E.g. a citiy or a space station. This place is defined by longitude, latitude and distance from the planets surface. Distance from the surface if you want to have e.g. cities in the sky.

 

Welcome to No Man's Sky 2.0 remastered Keep up the good work @Darkcoder
Expecting to see the new assets, this toolkit is just amazing.
Btw, i'm trying to make a tessellated planet (aka terrain) but i think i'm doing few things wrong as when i add the heightmap it just get weird heights and doesn't look a planet at all.
Any tips on how to make a nicely heighted planet? Also, as i didn't found many documentation about it, how does the mask map work? Thanks

 

Like NMS, except I want to hear everyone's crazy ideas so I can decide which implementation to go with

If you're talking about the SgtTerrain then the height is sampled from the alpha channel. Generating this texture is very difficult and either requires using a tool like the aforementioned Grand Designer, or writing some complex procedural generation code yourself. You can also look online for heightmaps of planets other people have made.

The Mask map is used to pick between detail textures, which helps break up the tiled appearance of these, so there's not much need to modify this.

I have no plans to integrate with any other asset, but either way I don't imagine any of these assets support spherical worlds. I plan to implement some kind of ocean though.

I have plans to add spawners that are much better than the existing ones. What do you mean by RGB channel though? Like you specify which objects spawn on which color? If so, how would the user paint or otherwise control these RGB regions?

Terrain blending with surface objects is an interesting idea. To make it seamless the bottom of the objects would have to be painted using almost the same shader as the planet surface though, so this kind of thing could be added later and wouldn't impact the way the terrain itself is designed.

This should already be possible, and will continue to be possible with the new terrain.

 

Yes, e.g.
red color channel = spawns gras
green color channel = spawns stones
blue color channel = spawns trees

This way you have full control of which objects spawn in which place on the planet and everyone can extend it for his own needs.

 

and the alpha channel could be used for the density of the objects

 

I see, well if this is completely separate then I guess it's easy enough to add. Perhaps there could be some kind of painting system for it that would also work on the terrain heights.

 

Another advatage is that this maps can be painted by an artist or a level designer. That makes the programmers live easier.

 

Well, I've got my own procedural tool for generating the heightmaps and most of the textures needed and it seems to work properly everywhere, so probably is about the inputs on my alpha channel and i just need few changes on the code to get it properly. Thanks!
So did you already thought of adding caves to the terrain? Or even better, some kind of "flying" terrain, such small islands floating around close to the surface? That would be a nice feature.
Also what about (i'm gonna call it) ring depth? Let's say you go 'inside' the ring instead of being just a flat texture?
As soon as I get some crazy ideas, i'll let you know definitely

Btw, about the city lights, you could try something as just lights from far away (outer space, keep in mind they should be detailed, you could try with some noise and layers to get that i think) and the closer you get, let's say you enter the atmosphere they could just blend with the environment to smoothly change into buildings? Just wondering xDD

For the water, you can manage to make a shader to add the foam, waves, fresnel, etc etc there are lots of them around and gets such nice outputs

EDIT: Apart of that, i think some improvements can be done with the procedural stars in spiral and all of that, to get the galaxy shapes. I will always think they are missing the ability to select every single star in there as if a gameobject :crying:

 

Alot of crazy ideas around here. This asset tends to be awesome.

 

Are you able to integrate Gravity Engine with the SgtFloatingPoint system? Because that's kind of important when you want *multiple* star systems...

 

There will be no caves or overhangs or floating islands, because these all require a fundamentally different terrain setup that I won't implement.

For now I will focus on the terrain, so I won't make any changes to the ring or starfield code.

I'll see what I can do about ocean stuff a bit later. Small waves and fresnel are easy enough, but making shore effects is difficult and I haven't researched it enough.

I'd like to experiment with city lights with the spawning stuff I mentioned before, we'll see.

If you have some reference videos for the kind of effects you'd like to see then I'd be interested to see (as long as they don't require the latest Direct3D 99 AI deep learning raytracing quantum computing effects).

 

https://assetstore.unity.com/packages/tools/terrain/cts-complete-terrain-shader-91938
Check this one out, i know is probably too expensive to make and taking lots of time. But on the other hand is a good reflection of the kind of effects we'd like to see when you are on close in the planet, however i know implement it will be hard but is just an example. Cause everyone here knows the potential of your asset, so you can get that as reference when talking about terrain.

 

Hi Darkcoder,
If an object in the scene has more than one material, how can I get the atmosphere component to render it?

 

How about combining the two?
You have a "fleet" of already LOD terrain with seamless border (basically the same idea as a big mesh but broken into tile). They don't have to adapt or tessellate, they just all slide together. The only difference is when approaching a pole or an edge, you need to hide some.

I have a code for area preserving spherification:

Code (CSharp):

1. public static Vector3 SQRspherized(Vector3 v){
2.         Vector3 v2 = new Vector3 (v.x*v.x, v.y*v.y, v.z*v.z);
3.         Vector3 a = new Vector3 (v2.x/2f, v2.y/2f, v2.z/2f);
4.         Vector3 s = new Vector3 (
5.             v.x * Mathf.Sqrt (1f - a.y-a.z + v2.y*v2.z / 3f),
6.             v.y * Mathf.Sqrt (1f - a.x-a.z + v2.x*v2.z / 3f),
7.             v.z * Mathf.Sqrt (1f - a.x-a.y + v2.x*v2.y / 3f));
8.         return s;}

explanation http://mathproofs.blogspot.com/2005/07/mapping-cube-to-sphere.html

There is an efficient shader version somewhere

Code (CSharp):

1. // Performs the mapping of the vector 'v' centered within the axis-aligned cube
2. // of dimensions [-1, 1]^3 to a vector centered within the unit sphere.
3. // The function expects 'v' to be within the cube (possibly unexpected results otherwise).
4. // Ref: http://mathproofs.blogspot.com/2005/07/mapping-cube-to-sphere.html
5. real3 MapCubeToSphere(real3 v)
6. {
7.     real3 v2 = v * v;
8.     real2 vr3 = v2.xy * rcp(3.0);
9.     return v * sqrt((real3)1.0 - 0.5 * v2.yzx - 0.5 * v2.zxy + vr3.yxx * v2.zzy);

This one comes from the Unity SRP repo, in CommonLighting.hlsl

and in case you need it:
https://www.iquilezles.org/www/articles/patchedsphere/patchedsphere.htm
http://paulbourke.net/miscellaneous/cubemaps/ (different mapping conversion)
Apparently this might help to, but haven't looked in depth
http://jcgt.org/published/0007/02/01/paper.pdf

 

Yeah I saw that, interesting stuff

If your object has multiple materials because it has multiple sub-meshes, then you can't. This is a limitation of how Unity works, because the last material will only apply to the last sub-mesh for some reason.

Thanks for the code links, I'll implement this when I'm happy with the terrain code.

I'd rather not make the terrain stuff complex by combining multiple approaches.

I've made more progress on the single mesh idea though, but I came across some issues. If I snap the points to the underlying cubemap then the terrain looks fine on any given frame, but since the mesh doesn't align exactly and it's constantly scrolling across, these points can snap to different pixels, which causes the terrain to pop a lot when moving which looks bad. I also experimented with generating the mesh from spherical coordinates and snapping the rotation to the rotational increments of this mesh, and while this works perfectly across one axis, this doesn't work at all along the other. Perhaps some kind of vertex morphing between each new snapped rotation would look acceptable.

 

I'm saying it's the simplest lol, sometimes combining make simpler, by taking only the simpler things.

ie think about it:
- if you have a single mesh, you lose the flexibility around pole, because the mesh won't bend properly or you will have swimming artefact. So you have to duplicate the huge mesh for each face, and since a sphere can be seen from space you can see up to 6 faces at a time. And even if you duplicate the mesh, it's a mesh designed to have all LOD feature in a single go, since it can't cross border or pole, you have a big problem to solve...

- Cdlod on the opposite said, is basically tessellating (if I don't mistake anything) and merging discontinuity of tile. That's a lot of micro management, as you must take care of of that. But since it's discrete tile, it doesn't have problem crossing the border at all. Because you just rearrange the tile when they get close to the poles or edges.


So the idea of combining strength is that:
1. you keep the main idea of the big mesh, ie just slide stuff and let vtf do magic
2. but just cut him into seamless chunk.
3. when you get to pole, reposition or hide chunk.

No rotation, no swimming vertices, no problem of alignement, no snap, no pop, no pain, no strain

The other thing I shared is just a better normalization code to avoid stretching. Then a few utilities that are optional.

Here is a quick proof of concept
https://github.com/Neoshaman/nomad-space/blob/master/project/planettest.cs