Search Unity

  1. Calling all beginners! Join the FPS Beginners Mods Challenge until December 13.
    Dismiss Notice
  2. It's Cyber Week at the Asset Store!
    Dismiss Notice

【50% OFF】⏱ Space Graphics Toolkit

Discussion in 'Assets and Asset Store' started by Darkcoder, Aug 18, 2012.

  1. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    1,675
    Well, the meshes I tried were basically variations of a semisphere that pointed toward the camera. This didn't have any issues with poles or cube faces, but it did have issues with changing orientation, because there's no way to lay out the vertices such that the semicircle can snap to any new rotation without there being an abrupt visual state change. The best was 1 axis of rotation, but you need 2 to cover the sphere.

    If I understand your concept correctly, you're talking about finding the nearest quad on a low detail cubed sphere (though each quad could be subdivided many times), and replacing it with a pre-generated high resolution mesh? If so, this is would indeed work, but it seems like the worst of both worlds. This makes the code more complex, you would have limited detail up close, and near chunk borders you would have to show the neighbours otherwise the transition would look bad.

    In any case, my CDLOD version works fast enough at over 1000 FPS with 8 million triangles on a 1:1 scale Earth (though there is basically no detail at this range due to each heightmap texel being 600km^2 lol), so I think this solution works fine. The tree structure also plays very well with spawning objects on the surface and colliders.
     
    dirkjacobasch and MasonWheeler like this.
  2. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    After a little bit of experimenting I could use the AQUAS Water/River Set asset to add water to my planet.

    SpaceRacing_63705145970175_2560X1440.jpg SpaceRacing_63705147207924_2560X1440.jpg SpaceRacing_63705147531309_2560X1440.jpg
     
    John-G, hopeful, joshua_42 and 3 others like this.
  3. MasonWheeler

    MasonWheeler

    Joined:
    Apr 2, 2016
    Posts:
    37
    The first and last one look good, but GAH! That second one is hideous! Doesn't AQUAS have a way to do water reflections that actually look like water, rather than Saran wrap?
     
  4. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    :DI thinks that's my bad settings. It is just a test with an water asset I have. What I really want is an ocean water asset. If you know a good ocean water asset let me know.:)
     
    MasonWheeler likes this.
  5. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    661
    I know it may be asking too much but if you ever found the time to do a sort of tutorial I would love to read it. This is something I need to figure out at some point but have no idea how to do. In my case I don't need to get right down to surface level but do what things looking good from an orbit level.
     
    rmorph likes this.
  6. joshua_42

    joshua_42

    Joined:
    Jun 23, 2016
    Posts:
    78
    I've managed to mix three heightmaps (and their texture-masks) and produced some variation in the terrain. The occasional unrealistic bit of terrain (mountains being chopped in half; erosion/flow going up hills etc) is a price I'm willing to pay for the variety it produces and I have some ideas on how to mitigate the worst of it. If I could reproduce the tiled heightmaps as an equirectangular projeted image I could use that image as a reference. For example, I could create a mask map for the biomes (heightmaps), isolate the channel I want to use for the mountains, lower its opacity so I can see the tiled heightmap (as SGT would produce it on the terrain), and paint out any area on the mask that cuts through a mountain. I can do this with just a tiled image but it obviously doesn't match when projected on a sphere.
    Can anyone recommend a way to turn an image into one that sgt terrain can use?

     
  7. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    Omg, how can I create this incredible height maps?
     
  8. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    Good idea. :)
     
  9. hopeful

    hopeful

    Joined:
    Nov 20, 2013
    Posts:
    4,960
    Have you looked into Crest? Community Ocean was doing okay for a while, but Crest may be past it by now.
     
  10. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    Thanks, that's exactly what I am looking for.:)
     
  11. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    I found the issue. I forgot to attach the needed scripts to the water gameobject. :) Now it looks better.
    SpaceRacing_63705217297906_2560X1440.jpg
     
    joshua_42 and MasonWheeler like this.
  12. joshua_42

    joshua_42

    Joined:
    Jun 23, 2016
    Posts:
    78
    dirkjacobasch likes this.
  13. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    1,675
    Wow, that looks incredible! :eek: I'm downloading the textures now, and I'll see if I can integrate them into the new terrain stuff. I plan to implement some kind of detail heightmap system with the new terrain that integrates into the biomes, so it should be much easier to add such things.

    My friend made a tool to auto generate spheremaps from any 2D texture almost 10 years ago, which you can get HERE. However, I can't get it to run any more. It probably requires you to install DirectX 9 or something, since it was made in DarkBASIC Pro.
     
    John-G, dirkjacobasch and joshua_42 like this.
  14. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    4,644
    Hey good discussion on planet generation.

    If you have an already working solution there is no point in continuing arguing implementation of the asset.
    I was merely offering some alternatives in case it would help you, it's been done and you have made your case about what works well in your specific context.

    But for the sake of geeking, let me defend my point more :D

    Basically the single mesh generation has a problem with swimming, it's inevitable because there is no consistant mapping on a sphere, pole are artefact of that, it's been proven with the hairy ball theorem https://en.wikipedia.org/wiki/Hairy_ball_theorem

    - So the first real question is are we okay with a bit of swimming and pop, if they aren't deal breaker, well a single mesh is the best easiest solution ever.

    - The second question is do we need consistant area, in my case I need generation driven by gameplay metrics, in order to have predictable sequences. The only way to mitigate the issue is actually to relax tension by adding more pole, you still has issue on pole, but it's now a matter of scale and region transition. BUT if you just need visually pleasing spawning or not that strict set of gameplay that depend on local proximity more, it doesn't matter really, pinching at planet scale will mostly be not detectable.

    The third question is basically spatial coherence, flat terrain have the most coherence, if you move the grid in integer values, it stay coherent there is no swimming, no pop. But you have to manage transition at pole.
    The more pole the more complex it is to mathematically manage region, apparently the optimal primitive is the isocahedron, I'm not that smart so my compromise was the cube sphere. It's basically just 3 flat terrain (equator loop and 2 polar cap) so inside those 3 regions its as good as .

    The solution I proposed is basically just slide a single "multi part" mesh in the "region" (a cube face) and trim at the border. Since you move inside a region by integer step, there is no swimming. Now the assumption is that when there is an integer transition to a less detail mesh (mesh chunk don't have to be uniformly tiling, nor they need to have a specific form, chunk is really there for hiding) that would pop when we cross the update threshold ...

    Well no because VTF would take care of that, you wouldn't just sample the map, you can use the MIPMAP, chunk are supposed to be always at the same range, low detail mesh are for distance viewing, they would simply blend based on distance (global hash value that tells how far from an update threshold) by sampling the mipmap at 2 level, so the height would simply adjust seamlessly to lower detail slope that match going from high density to low density, no fancy trick needed, you just sample!

    Therefore if you value the 3 points above, that's the simplest solution.
    - Make arbitrary mesh divided in convenient chunk, aligned on the integer grid
    - slide them through position offset hash within their region
    - handle "coherent region" transition by having the same mesh system duplicated and hide the chunk that cross region (min max detection really)
    - let VTF handle all the heightmap transition by just sampling it at various MIP

    In some way I regret getting carried and sharing that proof of concept, because the assumption behind it was not VTF, and as such I was focus on the behavior it showed, and not the actual code. The code isn't relevant as much as the behavior. :rolleyes:

    IN fact my goal was a bit motre insane than that, I want to bake distant field in a skybox, ie terrain beyond a distance are just rendered as texture, which is updated as we move from integer distance to integer distance, so That I don't support the cost or rendering them every fram, because no VTF and open gl 2.0 and playstation level of mobile power in vertex (300 000 poly throughput per frame at 60 fps in theory )
     
  15. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    1,675
    Hehe, we'll the code is never finalized, I'm always interested in thinking through the alternatives!

    I can see how your idea allows for fairly simple movement around the equator, since it's trivial to align each rotational step. I can imagine this would work well for lower detail planets, but I don't see how it solves any issues for bigger planets. For big planets you would still have to implement some kind of sudividing mesh based on distance, and for the pole this would basically require you to implement a traditional flat terrain, and then have that align with the equator mesh? Sounds tricky.

    Perhaps an approach like geometry clipmaps would be more suitable for your needs? I implemented a CPU only version of this in an earlier version of SGT, and it has some very good properties like 'free' LOD stitching, and it's quite easy to calculate the vertex data beyond the borders in a background thread to make movement very efficient. I ditched this approach because it requires a lot of minor Mesh updating, which at the time was slow in Unity because the Mesh API only allowed full vertex+index data updates, but recently they introduced partial updating, which should make this approach much more viable. I might have looked at this approach again, but I don't want to require Unity 2019.
     
  16. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    4,644
    I guess I explained badly lol. The reference we are using is still the cube sphere, the equatorial loop is an optimization, instead of considering each consecutive faces a single one, I just treat them as single band as they aligned perfectly and have continuity of direction. I could have chosen a band that goes through the polar cap but that make less sense with our perception of planet. Think about it, topological pole introduce change of direction (ie we have one less neighbor, this allow for curvature) but relatively to their edges, all quad have a direct "euclidean" neighbor, ie 8, In order to make thing easy I just decide to limit the pole problem to the ... pole of the planet (polar cap to avoid confusion ie top and down cube face, they don't have continuity of direction with the whole band), which generally have different biomes so it's even easier to hide potential discontinuity by explaining them away (pinching topological pole).

    Think about the typical cubemap texture T layout, you have a central band and two face that sticks out, they use the same strategy, they keep the cap to the azimuth and nadir and the horizon on the central band. So when we move thing we use the integer mapping to have all grid align perfectly. The cube face still has a major shift, well we reuse the same terrain technique and confine them to their cap region, the logic is the same so there is no preferential treatment. The thing is that before projection it's basically a 2D problem (you just translate the angular planet position to a projected 2d position), the VTF handle all the hard part, as it's the texture that ensure that everything is coherent and continuous.

    I should probably do some drawing but W10 isn't correctly compatible with bamboo.

    I looked at clipmap back in the day but that was way to complex for what they tried to achieve, with many chunk having different size and what not. I use this code to generate chunk position personally, I designed myself I don't know if there is an equivalent. In good old blitz3D.
    Code (CSharp):
    1. Graphics 800,600,0,2
    2. Origin 400,300
    3.  
    4. For i = 2 To 2^4
    5.  
    6.     ip = 2^(i-1)
    7.  
    8.     sn    = -2    * ip
    9.     se    = 2^i    - ip
    10.     sh     =           ip
    11.          
    12.     Rect se,se,        se,se,0        ;diagonal low right
    13.     Rect 0,se,        se,se,0        ;low low right
    14.     Rect se,0,        se,se,0        ;low right right
    15.  
    16.     Rect sn,sn,        sh,sh,0        ;diagonal high left
    17.     Rect -sh,sn,    sh,sh,0        ;high high left
    18.     Rect sn,-sh,    sh,sh,0        ;high left left
    19.  
    20.     Rect se,sn,        sh,sh,0        ;diagonal high right
    21.     Rect 0,sn,        sh,sh,0        ;high high right
    22.     Rect sh,-se,    se,se,0        ;high right right
    23.  
    24.     Rect sn,se,        se,se,0        ;diagonal low left
    25.     Rect -sh,se,    se,se,0        ;low low left
    26.     Rect sn,0,        se,se,0        ;low left left
    27.  
    28.     Print chebyshev (se,se)
    29.  
    30.     Delay 500
    31.     Flip
    32. Next
    33.  
    34. WaitKey()
    35. ;------------------------------------------------------
    36.  
    37.  
    38. Function Chebyshev (x1,y1, x2=0, y2=0)
    39.     Return max( Abs(x1-x2), Abs(y1-y2) )
    40. End Function
    41.  
    42.  
    43. Function max (a,b)
    44.  
    45.     If a > b Then
    46.         Return a
    47.     Else
    48.         Return b
    49.     EndIf
    50.  
    51. End Function
    Basically it create chunk in Power of two tiling as square ring, starting with the 4x4 center, with the property that if you remove the lower tile in the center, you can fill it neatly with 4 tile of the same size. Each chunk has the same subdivisions, and the same frange that connect to lower tile.

    About big planet:
    But the main idea that drive all my attempts at terrain, aside from gameplay metrics (i'm a designer, i'm not really a programmer, I hate code!), is that you want terrain right below you, that's what matter, basically a detailed terrain is like a big size shadow, as such I tend to prioritize terrain that are immediately interactable. That mean I chose to split the problem in half, the far field and the close field. I would use separate rendering technique because they have different concern, close must hold the complexity of interaction, far is mostly proxy visual. We just need to them to mesh correctly.

    The thing is that no matter the size of the planet, the close field will always have the same density, like in 2D game, I think of terrain has having a given size, unless planet are so small that the curvature shift the visible horizon, I just need the same size for all planet. For big planet, anything beyond can be whatever, generally the far field would use far sparser rendering and division. That mean when you get close to a planet, you generally only insert the close field after a certain distance and keep it that way (with smooth VTF height), it would just slide like a shadow beneath you, the far would always be far. That simplify a lot of thing IMHO because heightmap don't generally scale that much with planet size in term of usability.

    On a tangent, I have also start looking about octehedral mapping, the pain point with texture mapping on planet is teh ugly lat long deformation we get on pole, and managing 6 faces of a cubemap is bothering. Octohedral keep everything neatly as a square and apparently also have a cheap query function, much cheaper than lat long and cos.



    (this animation is just fine in edit, does not display in submit?)
    direct link: https://i.stack.imgur.com/PCB0U.gif

    I hadn't play with it, but I plan to do it to make a GI solution using a probe atlas with that.

    Code (CSharp):
    1. float2 OctahedronUV(float3 direction) {
    2.     float3 octant = sign(direction);
    3.  
    4.     // Scale the vector so |x| + |y| + |z| = 1 (surface of octahedron).
    5.     float sum = dot(direction, octant);    
    6.     float3 octahedron = direction / sum;
    7.  
    8.     // "Untuck" the corners using the same reflection across the diagonal as before.
    9.     // (A reflection is its own inverse transformation).
    10.     if(octahedron.z < 0) {
    11.         float3 absolute = abs(octahedron);
    12.         octahedron.xy = octant.xy
    13.                       * float2(1.0f - absolute.y, 1.0f - absolute.x);
    14.     }
    15.  
    16.     return octahedron.xy * 0.5f + 0.5f;
    17. }
    18.  
    19. float3 UVtoOctahedron(float2 uv) {
    20.     // Unpack the 0...1 range to the -1...1 unit square.
    21.     float3 position = float3(2.0f * (uv - 0.5f), 0);            
    22.  
    23.     // "Lift" the middle of the square to +1 z, and let it fall off linearly
    24.     // to z = 0 along the Manhattan metric diamond (absolute.x + absolute.y == 1),
    25.     // and to z = -1 at the corners where position.x and .y are both = +-1.
    26.     float2 absolute = abs(position.xy);
    27.     position.z = 1.0f - absolute.x - absolute.y;
    28.  
    29.     // "Tuck in" the corners by reflecting the xy position along the line y = 1 - x
    30.     // (in quadrant 1), and its mirrored image in the other quadrants.
    31.     if(position.z < 0) {
    32.         position.xy = sign(position.xy)
    33.                     * float2(1.0f - absolute.y, 1.0f - absolute.x);
    34.     }
    35.  
    36.     return position;
    37. }
    Code from https://gamedev.stackexchange.com/q...al-impostors-octahedral-mapping/169514#169514
    But in the URP/HDRP code source there is certainly an optimized version. It's becoming the standard in graphics circle, DDGI use it too, It's also used to pack normal map to a 2d system.
     
  17. joshua_42

    joshua_42

    Joined:
    Jun 23, 2016
    Posts:
    78
    Got the spheremap program working. I applied it to the terrain as the base texture but it doesn't match the geometry. It would be great if SGT could output it's combined heightmaps as an 8k texture so they could be worked on in other programs. The biggest problem I am having is with the maskmap not knowing anything about the detail height maps - so a combined height map seems like a simple solution that wouldn't involve SGT internally dealing with it. It could then be used to manually paint biomes; having control over the edge of a biome so it doesn't cut through a mountain/hill. You could even use it in an erosion program like Wilbur and run rivers through the terrain as an added bonus!

    I remember you mentioned you had tried some kind of interpolation on the terrain but didn't like the results - in the last video I posted the height maps tiling is set a forty and there are eleven LOD distances. There is more detail in the height maps but with terrain chunks larger than the pixels in the height maps it creates a sharp interpolation of sorts, which is still better than the voxel look you get with extra detail. Are you looking to add some kind of interpolation to the terrain?
    Regarding spawning objects, in particular - rocks. Maybe if one rock could spawn on flat ground that is near steep terrain it could then spawn other rocks around it (on the flat terrain)?

    I hope some of these are feasible for future updates.
    Cheers DC! :)
     
    MasonWheeler likes this.
  18. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    Hi @hopeful, I tested Crest water and it looks amazing but i have no idea how Crest will affect performance on a large planet. :)

    CrestWater.jpg
     
  19. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    1,675
    I see now, in that case I don't think it changes much in terms of code, because on a traditional cubed sphere the equator faces already trivial to connect together in terms of code and visually in terms of tangents or texture tiling.

    Octahedral spheres are indeed very interesting, and have great properties. I can see how mapping between a direction and UV is rather straightforward, and I imagine handling neighbours is also easier when stored in a tree. I'm not sure it solves much in terms of planet mapping though. Perhaps having a single tangent seam around the equator when using the dual dome mapping is preferable to cubed sphere's double U shape.


    I'm experimenting a lot with different approaches to every aspect of the terrain generation right now. Ultimately I don't want to have to rewrite this yet again in the future, so I want to nail it this time. For the heightmaps I will probably implement some kind of interpolation mixed with noise, because in my tests so far there's no way just heightmaps can make it look good enough.

    I will also greatly expand the object spawning system to have behaviours based on altitude, slope, biomes, splat maps, and maybe other factors if anyone has suggestions.

    Looks great, I'll use this as one of my references when implementing the ocean :)
     
  20. John-G

    John-G

    Joined:
    Mar 21, 2013
    Posts:
    1,113
    Simul Truesky has a great environment system which now includes an excellent water system.
    .

    Recent blog post showing better examples of the water system.
    https://simul.co/real-time-rendering-news/truesky-volumetric-water-tutorials-and-tips/
     
    Last edited: Sep 30, 2019
    Darkcoder and dirkjacobasch like this.
  21. Susihiisi

    Susihiisi

    Joined:
    Jan 11, 2018
    Posts:
    10
    This has been asked for many times, but is there any hope for volumetric clouds? I have tried for ages to find a solution and the only asset I know that supports spherical mapping, has problems with scale and it's tied to camera so it can't be placed on where I want it. I need clouds for real sized earth.
     
  22. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    1,675
    I can experiment with it.

    I've done 0 research into cloud rendering though, so any reference material would be great. I imagine some kind of ray marched approach would be required to make it look good. Implementing the whole sphere as one object sounds like it might require 4D noise which sounds expensive, so perhaps some sphere constructed from curved segments would save a lot of computation, like the SgtLightningSpawner does.
     
  23. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219

    https://github.com/przemyslawzaworski/Unity3D-CG-programming/blob/master/volumetric_clouds.shader
     
    MasonWheeler and Darkcoder like this.
  24. MasonWheeler

    MasonWheeler

    Joined:
    Apr 2, 2016
    Posts:
    37
    Found another weird problem. SgtFloatingOrbitVisual was working fine before, but now suddenly it's not displaying anything, either in the editor or gameplay. Tweaking the Thickness and Points values doesn't seem to do anything.

    Scene file attached. Any idea what the problem is this time?
     

    Attached Files:

  25. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    1,675
    You haven't assigned a material to the orbit MeshRenderer, when I do this it looks fine.
     
  26. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    1,675
    Hey everyone,

    Here's an update regarding the new terrain stuff.

    As I added more stuff to the CDLOD version, I noticed that it was getting pretty silly how many VTF calls I had to perform per vertex. Sampling just one heightmap is no problem, though up close this looked kind of bad with linear or smoothstep interpolation. This can be smoothed out with cubic interpolation, but this requires at least 3 more samples. I then need to augment it with noise which is multiple more samples and has the same interpolation issues. I then I have to do all of this 2 more times to calculate the normals and tangents. Not to mention I have to re-implement these calculations again on the CPU for collider generation and general height queries, which doesn't sound fun. These issues are making me rethink if this is the best approach for a general planet solution. Perhaps if it's just for planetary visualization with the ability to quickly zip across the surface it's great, but games need much more than this.

    So I decided to experiment with a different approach, which is CPU only multithreaded mesh generation. Here's a pic of this (without LOD stitching):



    This is on a procedural planet with the same 1:1 Earth radius, where the cube is 1x1x1 meter. As you can see, the performance is very good, even when generating new chunks. However, it still takes quite a long time to generate this much geometry, even across 8 threads on my i7-4790. I'll experiment with improving the generation order heuristics and split distance calculations to see if I can get it looking better, still not sure which approach is best. I have some other ideas I want to try too.
     
  27. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    4,644
    You sample noise from a texture?
    Try this, with SIMD you get 4 noise in a single call, then you need 2 lerps (better smoothstep), so in 3 expressions.
    i.xy = lerp(noise.xy, noise.zw,facteur)
    p = lerp(i.x, i.y)
    I think inigo quilez made a fast noise derivation too, never dabble into that.

    Sharing for more options ...
     
  28. MasonWheeler

    MasonWheeler

    Joined:
    Apr 2, 2016
    Posts:
    37
    OK, that worked! :)
     
  29. MasonWheeler

    MasonWheeler

    Joined:
    Apr 2, 2016
    Posts:
    37
    Bug report:

    In SgtAtmosphereOuter_Editor.OnInspector(), the DrawDefault call is looking for a property called "atmosphere" which doesn't exist, causing a NRE at design time. The property's name is "Atmosphere". Apparently case sensitivity matters here.
     
  30. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    1,675
    This is 15 octaves of simplex noise. I'll experiment with some alternatives soon!


    Good find, fixed it.
     
    neoshaman likes this.
  31. MasonWheeler

    MasonWheeler

    Joined:
    Apr 2, 2016
    Posts:
    37
    Using the same scene from this earlier post, attach a SgtRotate to the planet. Give it a high velocity, like Y: 100, for clarity. Then run it and watch how hideous the planet looks. You end up with something that is clearly a small, solid blue core with a translucent layer of planet-stuff painted over it at a much larger scale.

    This planet was copy/pasted directly from one of the Planet Pack 1 Tropical example planets. (Don't remember which one off the top of my head.) Going into those scenes and putting SgtRotate on the planets does not cause this weird visual effect, and I'm having trouble tracking down what it is that's doing it. Any idea what's going wrong here?
     
  32. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    Hi, with a little bit of help from joshua_42 I could make some good terrain texturing improvements.:)

    RS_1.jpg RS_2.jpg RS_3.jpg
     
    hjohnsen, Darkcoder and joshua_42 like this.
  33. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    Winter is coming so let's play with snow.:)

    SR_Snow.jpg
     
    hjohnsen, Darkcoder and joshua_42 like this.
  34. MasonWheeler

    MasonWheeler

    Joined:
    Apr 2, 2016
    Posts:
    37
    After a bunch of trial and error, I tracked this down. Apparently having the star emit a SgtLight is crucial to making the planets magically look good. Once I added that, it fixed it up.
     
    Darkcoder likes this.
  35. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    1,675
    Incredible!

    Sorry for the late reply. Components like SgtAtmosphere require SgtLight since they don't read normal Light data. If you enable Lit then the inspector should warn you if your scene doesn't contain any SgtLights though.




    On a different note, here's another terrain experiment ( SgtTerrain7 :D ). I implemented the planet seen in the previous screenshot (6371km radius, 22 LOD levels, 300km view distance here). This time using Unity's new Job system and Unity.Mathematics libraries, which apparently use SIMD for everything.



    My initial results weren't promising, because Unity's Simplex noise benchmarked around 10x slower than the FastNoise Simplex noise I was using before. However, once I enabled the burst compiler it was the other way around, and it was now 10x faster :eek:

    The issue of course is that the burst compiler only works with Unity's Job system, and the Job system only works with containers like NativeArray, and the Mesh class only works with NativeArray in Unity 2019.3.0, which isn't even out yet. These performance results are impressive though, I'll have to experiment a bit more :)
     
    Last edited: Oct 4, 2019
    Razmot, neoshaman, joshua_42 and 2 others like this.
  36. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    Awesome!

    I think there are some important decisions you need to make.
    • 1. Release date of the new asset. (If I remember correctly DOTS is out of preview in 2020)
    • 2. You need as much as possible performance to update meshes for large scale planets. This is possible with multithreaded code (DOTS)
    • 3. Is it possible to update the asset to DOTS later without much effort.
     
    MasonWheeler likes this.
  37. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    1,675
    These are important things to consider indeed!

    Luckily, my terrain experiments so far don't require the latest versions of Unity (perhaps 2018.3 or so). Updating meshes with native arrays is certainly nice to have, but copying to a Vector3 list shouldn't be too much of an issue. Most of the CPU is spent merging the meshes into good batches and updating MeshColliders. I don't think much can be done about the colliders, but I have some ideas on the batching. I'll be sure to send you a build soon :D
     
  38. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    That sounds great. Can't wait. :cool:
     
    Darkcoder likes this.
  39. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    4,644
    We are in business
     
    Darkcoder likes this.
  40. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    Feature request for the new asset.:D

    I am experimenting with detail texture / normal fading by camera distance. Everything is done in the planet shader and work well so far.This could be a feature for the new asset because it prevents this anoying texture tiling visible from space. Detail textures normally tiled a lot to look good in close range, but this tiling looks extremly bad from far away. That's why I fade them in if the camera is close enough for details. :)
     
    MasonWheeler and hopeful like this.
  41. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    661
    Hi there. Just out of curiosity more than anything, but why is the included Geosphere models so much larger than the stock Sphere? I just spent a good hour wondering why sizes of things were off and this ended up being why.
     
  42. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    For me it is only two times bigger but it is indeed bigger. Does this mean my planets are 1000km instead of 500km. :D
     
  43. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    661
    Two times bigger is a lot bigger :)
     
  44. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    1,675
    I'm currently experimenting with the detail tiling. In a previous experiment I made it so the detail levels constantly fade between one resolution and then twice the resolution based on camera distance. This looked pretty good, but it doesn't work on really big planets because of floating precision issues.


    The SGT spheres have a radius of 1, which I think makes sense, whereas the Unity one has a diameter of 1.
     
  45. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    219
    I use this to fade textures and normals in and out in my experiment. _FadeFactor is defined by the dev in the shader and is a relative high value which depends on when the fading should start. For my 600km planet it is around 10000.

    Code (CSharp):
    1. half dist = distance(i.worldPos, _WorldSpaceCameraPos);
    2. half texFadeFactor = (1 / dist) * _FadeFactor;
    3.  
    4. // Fade normal of the second main texture
    5. o.Normal = BlendNormals(UnpackScaleNormal(tex2D(_BumpMap, coord), _BumpScale), UnpackScaleNormal(tex2D(_BumpMapSecondTex, coord * _SecondTexTiling), clamp((_BumpScale2 *  texFadeFactor), 0, _BumpScale2)));
    6.  
    7. .
    8. .
    9. .
    10.  
    11. // Fade detail textures
    12. o.Albedo += diffuseColor * clamp(texFadeFactor, 0.0, 1.0);

    Please write that in the documentation if it's not there because everyone think it's the diameter.;)
     
    Darkcoder likes this.
  46. Susihiisi

    Susihiisi

    Joined:
    Jan 11, 2018
    Posts:
    10
    When can we expect this new planet system? Meow.
     
  47. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    661
    Has anyone looked into using Substance to dynamically generate textures for planets?
     
  48. Titan2105

    Titan2105

    Joined:
    Feb 20, 2019
    Posts:
    3
    PlanetTest.png
    That look's really awesome Joshua, how did u mix the three heightmaps and masks if you don't mind me asking? I'm having trouble getting detail like this mountains seem to be cut in half, I've added a screen shot of what I end up with.
     
    dirkjacobasch likes this.
  49. hopeful

    hopeful

    Joined:
    Nov 20, 2013
    Posts:
    4,960
    Substance is still pretty broken, IIRC. It's taking them ages to get it back to where it was.
     
  50. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    4,644
    How about a custom render texture to benefit:
    - the parallelism of GPU
    - the async of custom render texture
    - the partial rendering of custom render texture
    - the circular buffer of smart implementation

    I still have to work on the close terrain for gameplay if I use sgt, so I'm still working on terrain too lol