Planetary Terrain: Quadtree Planets for Unity

Can anyone report how collisions work in medium sized planets? (I supposse with big planets the collision system doesn't work).
Are the collisions with terrain accurate enough?
Thanks

 

Collisions work on planets of all sizes, small or large, with just as much precision as they would have on any other terrain. You can place any fps or vehicle controller (that supports spherical gravity) on the surface of e.g. the earth-sized planet, and it will work just fine.

Colliders are generated on a per-quad basis, and since quads where colliders are needed are always close to the player (and therefore origin), floating point inaccuracy isn't a problem for colliders. Even if a quad would be too far away, the rigidbodies colliding with it would start acting weird before the collider would. It really isn't an issue.

 

Any chance you will release your floating point origin fix by itself? I don't need a planet generator.

 

http://wiki.unity3d.com/index.php/Floating_Origin

Check out this one.

 

It's insanely simple, looks something like this in pseudo code

if player.position.magnitude > 5000 then

    for all objects do

        object.position -= player.position

    player.position = zero

 

Oh, so it just resets the position of the player and objects at a certain distance distance. That is insanely simple and very clever. Thanks for sharing.

 

I've just updated to the more recent version (in unity 2018 3.2f1).

The first thing I had to do was delete fade.cs as it conflicts with oculus (which already uses "fade").

Now all I get is the errors below.... I can get the asset working but only if I completely delete the node editor folder (shame as it looks like a cool feature I'd like to use).


Assets/Planetary Terrain/Scripts/xNode/Nodes/ComputeShaderGenerator.cs(11,24): error CS0234: The type or namespace name `DoubleMath' does not exist in the namespace `PlanetaryTerrain'. Are you missing an assembly reference?
Assets/Planetary Terrain/Scripts/xNode/Nodes/ComputeShaderGenerator.cs(20,52): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/ComputeShaderGenerator.cs(270,45): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/ComputeShaderGenerator.cs(270,60): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/ComputeShaderGenerator.cs(283,36): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/ComputeShaderGenerator.cs(283,87): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/ComputeShaderGenerator.cs(298,42): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/ComputeShaderGenerator.cs(298,64): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/ComputeShaderGenerator.cs(331,27): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/ComputeShaderGenerator.cs(331,37): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/PTNode.cs(15,9): error CS0246: The type or namespace name `Heightmap' could not be found. Are you missing `QuadtreePlanet' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/PTNode.cs(19,20): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/FromSavedNode.cs(18,23): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/GeneratorNode.cs(14,12): error CS0246: The type or namespace name `NoiseType' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/GeneratorNode.cs(15,12): error CS0246: The type or namespace name `FractalType' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/GeneratorNode.cs(33,23): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/OperatorNode.cs(18,12): error CS0246: The type or namespace name `OperatorType' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/OperatorNode.cs(21,12): error CS0246: The type or namespace name `OperatorType' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/OperatorNode.cs(24,23): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/PreviewNode.cs(52,23): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/PTNode.cs(35,12): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?
Assets/Planetary Terrain/Scripts/xNode/Nodes/PTNode.cs(44,26): error CS0246: The type or namespace name `Module' could not be found. Are you missing `QuadtreePlanet.NoiseGeneration' or `System.Reflection' using directive?

 

I also have another problem. I really want to adjust the heights of the individual tetures, but the UI is broken and I have no way to alter them.

 

I renamed the namespace from QuadtreePlanet to PlanetaryTerrain in the last release, and some scripts didn't get updated in your project. Just delete the whole PlanetaryTerrain folder an then import the latest version.

Your other problem is a Unity bug. I already reported it to them once, they were able to reproduce it and said that they had fixed it. Their fix didn't work though as it is still present in the latest version. I guess I'll report it again. Anyway, to work around it just use the debug tab.

 

Great thanks, I've found the debug settings. I'm having trouble achieving the effect I'm after. I was hoping I could adjust it so I could have multiple textures appearing at the same level, over each other at different scales to create an LOD effect. Am I right in thinking its limited to have one texture at one height, the next texture at a different height? And all you can adjust is the height of the transition?

Would love to be able to set a low-high range for each texture, or at least be able to set multiple textures at each height (3 layers of beach, 3 layers of mountain etc.).

 

Hey simitro, is it possible to make smaller quads (255 triangles max) to allow all of the colliders to be convex? If so, would this effect performance or functionality in any significant way?

 

Yeah, the current system can only fade between two textures at a time. I'll look into your idea with a low-high range for every texture.

 

It's certainly possible, you could make the quads 15 by 15 vertices (has to be odd). I suspect general performance would be a bit worse as more Quad-objects are required for the same number of vertices. Some features (like GPU terrain generation) would be more difficult to re-implement, but to get the basic system working you just need a quad with same index order as the standard one and corresponding triangle arrays for edge fans.

 

Hey simitro. Looks like you've improved a lot since my reviews back in the day.
Are you planning to add splat map support instead of just height-based texturing?

 

Thanks! Currently there is the biome map, a second heightmap that overrides the first one when selecting textures. You are still bound to the predefined gradient though. I will implement a proper splat map for the next release.

 

I haven't looked at the code in a while but it sounds like @simitro might have forgotten to put "#if UNITY_EDITOR ... #endif" around some block of code, or something that was meant for the editor assembly somehow got into the build. In any case it's probably fixable, but you may have to wait for the official fix.

 

Taylank was right, I was missing the #if UNITY_EDITOR in a script. Just replace Planetary Terrain/Scripts/xNode/Nodes/ComputeShaderGenerator.cs with the attached script. Sorry, my mistake. Should have tested building it once more...

 

No update on this asset?

 

Will be out soon!

 

Planetary Terrain 3.0 is out now!

Changes
General
- Heightmaps now encode width, height and bit depth. Use to "Old To New Heightmap" utility to upgrade old heightmaps
- Major performance improvements (idle, generation and foliage)
- Quad size (vertices) can now be customized, no longer bound to 33
- Added events and delegate voids called when entering/leaving Scaled Space and when Quad generation is finished
- Added new experimental quad-independent foliage backend
- New xNode version 1.6
- Added new atmosphere shader based on the Brunetons Improved Atmosphere port by Scrawk
Texturing
- Added visual editor for texture gradient
- Added texturing based on range set for each texture
- Added splatmap-based texturing
Generation
- Added heightmap node, you can now use heightmaps in the Node Editor.
- Added Streaming Heightmap generation mode. Allows the use of very large heightmaps by only loading a part of them.

Splatmap + Foliage System

Custom Quad size (e.g. 13x13)


Double Edge Fans


Streaming Heightmap (Usually low-res data is used outside of the loaded area. This was disabled here to visualize the system better.)

The next update will focus on improving the shaders and visuals in general. Also excited to use Unity.Mathematics and ECS/Burst Compiler once they are ready for production.
I also tried to improve things that were criticized and greatly extended the docs. If you feel like anything has changed please write or update your review to let me know. Thanks!

Please also let me know if you find any bugs or would like a new feature!

 

I have a couple of requests:

1) An option to assign generated quads to a layer, or make them inherit Planet object's layer
2) A function that can be called at runtime to refresh/update/reload generation data (to potentially allow for runtime planet editing)

 

Hey @simitro - Got a few questions for you about this asset.

1. Can we get a screen shot or a video of the new Atmospheric Shader in action?
2. Does the foliage system take advantage of instancing?
3. How did you do the water for the oceans?

 

1) Sure.
2) I can do that, would be rather slow though as every quad has to regenerate its mesh. Maybe a big coroutine for a global update and a faster function that updates only one quad and all its parents. I'll look into it.

1) Here you go:


I'm also working on a post-processing atmosphere shader. It is not used in any of the sample scenes as it still has some issues, it is included (as experimental) though. (Attach Atmosphere Post Processing to your far camera and assign the RenderSky material.)


2) It does. For prefabs you can set everything up yourself, so you just need to use an instancing-enabled material. Meshes rendered without GameObjects can also be rendered using instancing ("Use Instancing" toggle). Grass is rendered as a single point-cloud mesh per quad, so instancing is not required.

3) An ocean is just a second, flat planet. This works fairly well with basic water shaders, more advanced ones often require (0, 1, 0) to be "up" though and are therefore usually not supported. In the next update I'll focus on the visuals, a new ocean shader is one of my priorities.

 

@simitro Might be useful for runtime retrieval of compute shader data:

https://docs.unity3d.com/2018.1/Doc.../Experimental.Rendering.AsyncGPUReadback.html

 

I have another small request: an option to automatically parent all generated meshes to a chosen game object (or the planet object).
Thanks for considering requests!

 

Is already being used in all Unity versions where it is non-experimental.

 

That's also easy, the GameObject needs to be at the origin, have scale one and rotation zero though, to avoid messing with the positioning. I could also add a List of all Quad-GameObjects to make looping through them easier.

Thanks for requesting!

 

@simitro For my use case, I need to handle planetary motion in another script to make it work with my character controller. Moving platforms (or in this case quads) also need to have a rigidbody component. Doing this to a list of quads would probably far less performant than the workaround of just doing it to a parent object. I also have multiple planets in my scene. Would converting quad calculations to local space be a total mess? Is there another solution?

 

The planet Transform/GameObject already acts as a sort of parent object for quads. If you change transform.position (of a planet's transform) the quads will move along. You can rotate a planet by changing Planet.rotation.

In earlier versions quads actually were just children of the planet's transform. That caused some precision problems though, since Unity's transformations are only done with floats. Quads are now independent transforms, their positions are calculated in Planet.UpdatePosition(), where all values are converted to double-precision data types beforehand.

Even though doubles are used, and it is not (unlike Unity's transforms) in native code, UpdatePosition() is still very fast. Would be even faster with a dedicated renderedQuad list to loop through, I'll add that.

Still seems somewhat counter-intuitive to move the planet instead of the character controller though, is there no way to adapt it? Translating a planet isn't the most expensive thing, but it would certainly be faster to have the character controller handle everything itself.

 

I’ve been using a custom planet editor I made as a placeholder for prototyping. It is not optimized enough to facilitate high resolution meshes performantly. However, I have a character controller that can move from planet to planet, each with its own gravity/rotation/orbit, and traverse the surface as if it is not moving at all from the players perspective (except for everything moving in the sky, of course).

When I get a chance I’ll experiment with performing the planetary movement calculations and then applying the results to an empty object with a rigidbody and copy the final pos/rot to the planet each frame. Kinda hacky, but maybe not too expensive (if it will work at all).

I imagine the precision problems are mostly for extremely large planets? I don’t anticipate my planets being anywhere near the scale of real planets. I’ve been prototyping with planets with a diameter of 2000 units and below and probably won’t go bigger than about 3x that.

 

Yeah, with small planets you can go back to just making quads children of the planet transform. The relevant code that instantiates new quad-GameObjects or gets them from the pool is in Pools.cs QuadGameObjectPool.GetGameObject(). Just set your planet as the parent of the new quad-GameObjects.

Then you can get rid of Planet.UpdatePosition(). You also need to replace planet.rotation (double-Quaternion used for increased precision) with the usual planet.transform.rotation. Let me know if you have any problems getting it to work!

 

@simitro I appreciate the guidance!

 

how can I identify the generated quad when I use the finished generating quad event?

 

You can't unfortunately. It is a more general event called when the planet has finished generating all quads it needs to after starting a scene or moving the camera. That's why it is called OnFinishedGeneratingQuads. If you need to add any code that's called every time a quad has been generated, you can add it the the bottom of Split() in Quad.cs (apply it to all in children[]) or in ApplyToMesh() in Quad.cs.

 

Does anyone have experience using this with a VR Headset? I took the demoscene and startted it with open VR, but the cameras behave very weird (it renders 2 planets which are stuck into another, one is acting correcting when looking around, the other makes you dizzy right away bacuse it behaves weird related to the rotation of the headset)...any ideas? Nothing abou VR in the documentation. :-(

 

I already got it working once using the SteamVR plug in. The problem probably has to do with PT using multiple cameras (near, far and scaled space) often times.

The near and far cameras always have to be in the same place (far camera is child of near camera). Positioning of the scaled space camera is handled by the Scaled Space script, just assign the near camera transform.

I would suggest first trying to get a simpler scene with only one camera to work, e.g. the FPS Controller sample scene (just delete the controller and then add the Camera Move script to a new camera tagged Main Camera).

If you still need help I'll have a look in the next few days!

 

FPS Demo Scene works fine. So how do I have to set up the camera objects and the camera rig itself (it does not really matter if it is steam, oculus or unity native solution for the moment) so that it works in the other scenes (e.g. the earth scene).

Thanks for helping
Hannes

 

I got the near and far cameras working today (in SteamVR just duplicate the normal camera in [CameraRig] and set it up as your far camera, don't child it!). Still having some difficulties with the ScaledSpaceCamera though, I will try again tomorrow.

 

Ok, it's easier than I thought. Just the following to get e.g. the Earth-sized Planet scene working with OpenVR

1) Unchild the Far Camera from the Near Camera. Both are automatically tracked, there's no need to child it.
2) Add a Tracked Pose Driver to the ScaledSpaceCamera, set Pose Source to Head; Tracking Type to Rotation Only; Update type to Update.

That should do it. Contact me if you still have any issues!

 

Just added this to a clean new project and opened the demo scene in 2019.2.0a7 and get a lot of errors similar to:
Assets\3PP\Planetary Terrain\Scripts\Math\Math.cs(186,23): error CS0104: 'Vector3d' is an ambiguous reference between 'PlanetaryTerrain.DoubleMath.Vector3d' and 'UnityEngine.Vector3d'

I changed all these to DoubleMath.Vector3d and can load the desert planet sample. The FPS demo scene doesnt work with a ton of errors. The GPU instancing scene runs but when you move closer to the planet the landscape disappears.

The landscape for the earth in the "system" scene doesnt work with Object reference not set on line Planet.cs:359:
Vector3 camPos = mainCameraTr.position;



When i follow your documentation, on Getting Started step 2, generating a heightmap for a planet, this does not work as described, instead I get this in the console:

System.Runtime.Serialization.SerializationException: No map for object '201326592'.

followed by a ton of errors.

Is this asset completely broken in 2019.2?

 

I have run into a strange issue with imported heightmaps. I started with a 16k x 8k raw file, and converted it to a heightmap. Close to the surface, I notice a strange grid pattern:



Note that the large grid is solid, then those are composed of smaller squares of dotted lines, those are subdivided again, and the last square has a dot in the middle.
I don't see much of a difference if I check "Use Bicubic" or not.
These artifacts are NOT present in the original height png. Any idea what is going on here?

 

You're right, seems like the Unity alpha is causing these issues. Will look into it.

How large is the planet you're using the heightmap on? Do the artifacts also appear on smaller planets, or on planets with fever subdivision levels?

Unfortunately this looks to me like the floating point precision limit. Relatively easy to "fix" by just doing all the math with doubles, would obviously be far slower though. Seems odd to me that you're reaching it when just using a heightmap because of the limited detail they have. How many subdivision levels do you have, and do you really need that many?

I'll try adding a define/toggle to switch to a double-precision mode.

 

I had a bit more time to experiment, and it's absolutely related to the detail levels, and not the size of the planet.

The planet I want to make (and shown above) is 475,000 units in radius. My detail distances array is size 8-9, I didn't experiment with much variations there yet. Detail distances calculator starts at 2,500,000.

For a test, I just tried a 100,000 radius planet, with the detail levels set to size 6, same heightmap, detail distances calculator starts at 500000, and it looks ok.
I expand the size of the details array to 7, and the artifacts appear again, just not as clearly. Settting the detail levels to 8 and the artifacts become very clear again.

I then made a planet 5000 unit radius, distance calculator 25,000, with 8 detail levels, same heightmap, and I can see the artifacts.

It seems that the size of the planet doesnt matter, but for detail levels 7 and higher the artifacts appear, the higher the detail level, the clearer the patterns become.

I am just experimenting with with various parameters so far to get a nice result. I can't really say what I need yet, but I notice that my planet looks all smoothed and blurred out if I have lower detail levels. I want crisp , sharp geometry as much as possible. I've been adding in extremely high frequency noise along with the hieightmap in Hybrid mode (this extras noise is not included in the screenshot above) but I find that I need these high detail levels, maybe even higher, otherwise everything looks like soft, gently rolling hills when flying near the surface. If there's a better way to get rougher, more detailed terrain I'd be grateful to hear about it.

 

The terrain is generated while the planet is still at a radius of one, so the problem being unrelated to the planet just points to floating point accuracy again. I only ever had these problems with way higher subdivisions though, I'd be grateful if you could send me your project so I can have a detailed look at it.

The smooth terrain is the product of interpolation. Without it you'd just see pixel-like blocky chunks of terrain, with it those chunks are smoothed, especially with bicubic interpolation. At some point, if you add more subdivision levels it will just make the terrain smoother.

You can get around that by using higher-res heightmaps (take a look at streaming heightmaps), or by incorporating noise into the terrain generation, either with hybrid mode or using pure noise.

 

I created a discord server for support, suggestions and such. Feel free to join!

 

Can this be used with voxeland or uterrain? Also, can I use my own heightmap instead of generating one? I want to build a voxel model of Mars and wanted to use my own heightmaps to represent the main geographical landmarks of Mars such as Olympus Mons or Valles Marineris. In other words, would I be able to patch together a bunch of my own heightmaps to make a planet and use that planet with voxeland or uterrain to get the voxel aspect that I'm looking for? Thanks in advance!

 

1) Unfortunately there's no support for any other terrain assets.
2) Sure, it just needs to be an equirectangular heightmap.
3) PT isn't using voxels in any way, that's just unrealistic for terrains as large as planets. The required memory would be huge, even when using very large voxels.
4) Combining heightmaps of different qualities is still easy though. You'd have to write some custom code for the streaming heightmap, contact me if you need help.

 

Edit: Fix is out

Deserialization fails in 2019.1, this is because the noise modules are saved with the wrong extension.

To use noise modules, change their extension from .txt to .bytes to signalize that the TextAssets contain binary data. The three included noise modules can be found in Planetary Terrain/Noise Modules/: noiseEarthLike, noiseFPSControllerPlanet and noiseSmallEarthLike.

You can also edit the line that gives new noise modules their extension, SavingNode.cs

GetInputValue<ModuleWrapper>("input", null).m.Serialize(new FileStream(Application.dataPath + "/" + filename + ".txt", FileMode.Create));

Just replace ".txt" with ".bytes". Fix will be out soon.

I'll also transition PT to use Unity.Mathematics and Burst now that they are out. Stay tuned!

 

I'm reading Planetary terrain uses multiple cameras.
As in my game project I use one camera for on land action and another for flying-in-a-ship action (the game swichts between cameras runtime) I'm afraid it is going to be tricky to configure that.

Any clarification?

BTW please, could I see the asset documentation (PDF)?

 

Yeah, PT uses multiple cameras. One near camera, one far camera (which is just a child of the near camera), and a scaled space camera. Switching is really not an issue though:

You'll just need a near and far camera for each single camera you have right now. Then you can enabled/disable the near and far camera just like you would with your single camera.

Every time you switch you also need to set the following variables to the active near camera: ScaledSpace.mainCamera (Transform), Planet.mainCamera (Camera, make public), Planet.mainCameraTr (Transform, make public).

Alternatively, you could just teleport cameras instead of switching between them.

Documentation is attached.