Planetary Terrain: Quadtree Planets for Unity

This is a little confusing but I will read the docs. Thanks.

 

Hi simitro.
I purchased the asset and test the FPS Controller. When the planet doesn't moving, is correct but when the planet is rotate, the FPS on the surface doesn't have force rotation.
Is planned to fix it and/or how I can solve it ?

Also for Atmosphere, is possible to have more documentation ?

 

Is your issue that the FPS Controller is not moved along with the surface? That can be resolved like so:
Just attach the Rotate Around Planet script to your FPS Controller, assign your planet as Parent Planet and set Rotation Speed to the same value as you did on the Rotate script.

Which atmosphere model are you using (Atmosphere (old) or Atmosphere Mesh), and what are you having difficulties with? I am happy to clarify anything or add a section to the docs!

 

I use Atmosphere (old) (isn't Atmosphere Mesh).
Thanks also for a solve with the problem above, I will test.

 

Any specific things you want me to explain more thoroughly, or just a bigger general overview? The shader is based on this one which is a port of the GPU Gems Atmospheric Scattering.

 

When I use it and add this, I have a black atmosphere with any change (here I want blue for example). Here screenshots (I put a sphere to the Directional Light for show where is the "Sun") :

 

I see. The atmosphere shader is designed for larger planets, therefore some tweaking is necessary to get good results with a smaller one. I attached an edited version of the script which allows you to move the atmosphere higher (Atmosphere Height slider, default is 0.5). Couple that with an increased Hdr Exposure and you should get better results.

 

Thanks but I have the same problem so I change to a another script for Atmosphere.
Some questions
For "SphericalGravity", is update automatically if the Planet set on "FPSController" change or we need to change also ? I see a your example on the scene System so I try to retry (for test, I reduce distance and size) with the FPSController. I think is can be a new section for your guide/scene example.
Quads can support shadow like eclipse. I have a another pack for make eclipse and put this on the Planet object but the shadow doesn't show on the Quad. I don't know for this if I contact you or the author of the other pack.
Thanks in advance.

 

Atmosphere works for me if you set Atmosphere height to 0.5 and HDR Exposure to something like 5 or higher.


I'm sorry, I don't understand your other question. There's really nothing you need to do at runtime when using Spherical Gravity, just make sure all GameObjects that should be attracted are in the Objects array. You don't need to do anything in Update.

I doubt that your eclipse pack is compatible, sorry. Maybe try attaching it to the Quad GameObjects directly (you can enable those by disabling "Hide Quads in Hierarchy")?

 

Hi Simitro,

I am tying to use Brunetons Improved Atmosphere on planet with radius 10000. I am gettin this error:

RenderTexture.Create failed: format unsupported for random writes - RGBA32 SFloat (52).
UnityEngine.RenderTexture:Create()
PlanetaryTerrain.Atmosphere.TextureBuffer:NewRenderTexture2D(Int32, Int32, Boolean) (at Assets/Planetary Terrain/Scripts/BrunetonsImprovedAtmosphere/TextureBuffer.cs:203)
PlanetaryTerrain.Atmosphere.TextureBuffer:NewTexture2DArray(Int32, Int32, Boolean) (at Assets/Planetary Terrain/Scripts/BrunetonsImprovedAtmosphere/TextureBuffer.cs:137)
PlanetaryTerrain.Atmosphere.TextureBuffer:.ctor(Boolean) (at Assets/Planetary Terrain/Scripts/BrunetonsImprovedAtmosphere/TextureBuffer.cs:35)
PlanetaryTerrain.Atmosphere.Model:Init(ComputeShader, Int32) (at Assets/Planetary Terrain/Scripts/BrunetonsImprovedAtmosphere/Model.cs:317)
PlanetaryTerrain.Atmosphere.AtmosphereMesh:Start() (at Assets/Planetary Terrain/Scripts/BrunetonsImprovedAtmosphere/AtmosphereMesh.cs:163)

This is just one error which comes repeatedly. Others are:

Kernel 'ClearTex2D' not found
UnityEngine.ComputeShader:FindKernel(String)
PlanetaryTerrain.Atmosphere.TextureBuffer:ClearTexture(ComputeShader, RenderTexture) (at Assets/Planetary Terrain/Scripts/BrunetonsImprovedAtmosphere/TextureBuffer.cs:184)
PlanetaryTerrain.Atmosphere.TextureBuffer:Clear(ComputeShader) (at Assets/Planetary Terrain/Scripts/BrunetonsImprovedAtmosphere/TextureBuffer.cs:105)
PlanetaryTerrain.Atmosphere.Model:Init(ComputeShader, Int32) (at Assets/Planetary Terrain/Scripts/BrunetonsImprovedAtmosphere/Model.cs:318)
PlanetaryTerrain.Atmosphere.AtmosphereMesh:Start() (at Assets/Planetary Terrain/Scripts/BrunetonsImprovedAtmosphere/AtmosphereMesh.cs:163)

and an argument exception related to this kernel. I am not sure what is going on. What do you think I can do?

I am on Unity 2019.1.1

EDIT: This seems to be a version control issue. I tried on the master project on the master computer and none of those errors appeared.

 

However, this time I have another issue: terrain textures are sometimes rendered as black. There are large black areas on the textures on surface.

 

The intensity of each of the six textures is stored in the four vertex colors plus the two uv4 channels. If the intensity of every texture is zero, the shader will simply render black. Take another look at Textures in the Visual tab, specifically the Texture Selection Type. With Gradient you shouldn't get any black spots, please send me a screenshot if you do. With Range you get black spots if there are black areas visible in the preview. With Splatmap you get black spots if every channel is zero at a given point. If None is selected, the whole planet will be black when using PT's built-in materials.

 

The docs says nothing about all the camera setup required. Also Scaled Space camera concept is not well explained. I expected this asset to be better prepared for multicamera situations,(flying in space and landing-walking on planet).In these cases two cameras system is the easiest solution.

 

You're right, will add a section. As I said, multi-camera is no problem at all, you just need to get used to the complexity of three cameras. I can send you an example scene with a multi-camera setup if that would help.
What would you want me to add to the scaled space explanation?

 

I think the explanation makes it seem too complex.
Wouldn't it be easier to change the planet object by a simple sphere mesh with a colormap texture applied? (deactivating the planet object and activating the sphere impostor, and viceversa, depending on distance)
About far and near cameras I don't see why they are necessary.

 

The enabling/disabling a sphere object is basically what already happens, it's just integrated into the planet script. I will make a separate script if that simplifies things and also simplify the explanation.

You're right, for smaller scenes near and far cameras are not necessary. But as planets get bigger and we need a larger render distance, you start to get z-buffer issues as the clipping planes are very far apart. Splitting the depth into two cameras helps avoid this. This is also why near and far cameras are only used in scenes with large planets.

 

You also get issues with shadows... if the camera far distance is very big, the resolution of the shadows near the camera get very low. For this reason I recommend experimenting with a cockpit camera, which has a very short far distance, like some 10's of unity units, and another camera for the external stuff. You will get very nice crisp shadows in your cockpit. Note that Unity has a very annoying feature that shadows fade away as they approach the camera far distance, creating ugly bands of no shadow where the two cameras overlap, but there's not much you can do about it. See: https://forum.unity.com/threads/shadow-fadeoff-approaching-far-clip-plane.356893/

 

In my project I use other assets as GPUInstancer and this one depends on the active camera in the scene to work.
I'm afraid the far- near camera setup is going to interfere with that asset and others related to the scene camera.

 

I'm fairly sure these assets would work just fine if you declare the near or far camera as your scene camera.
If not, you are unfortunately bound to small planets, as this is a technical limitation of Unity's 32-bit depth I can't do anything about.

 

You could also perhaps change the other assets to not rely on camera.main but be provided with a reference to a specific camera?

I was vaguely thinking of trying GPUinstancer to scatter tons of rocks around on my planet. If you have any success (or negative experiences) in this area please let us know, as I guess many of us are wrestling with similar problems when working with large scale planets.

 

If finally I decide to buy PT I will report my experience of integration with GPUInstancer and another assets I use concerning cameras on scene.

 

Can you provide some info on the streaming heightmap?
The documentation just says I need a .bytes file. What format should this have? What mapping should it use, how are the coordinates for the detailed areas specified...

 

It's just a normal PT .bytes file, a normal heightmap file like you would use anywhere else in PT, just way larger usually.
You don't need to specify any coordinates, the relevant area around the player is always kept in memory. You just need to set the size of that area, and the movement threshold after which said area is reloaded.

 

Sorry, but this isnt anywhere near enough information to implement. I dont know what the format of a PT file is either, there's utilities for generating them from textures.

 

The PT file format is very simple. As described in the docs, it has a 9-byte header encoding width, height (both little endian 4-byte signed int) and is16bit (1-byte, true if nonzero). The raw bytes/ushorts follow, in little endian order, indexed with [y * width + x], (0,0) is lower left. You can import heightmaps from Unity textures with Planetary Terrain -> Utils ->Texture Heightmap to RAW, or from .raw files and uncompressed tiffs with Planetary Terrain -> Utils -> Heightmap Importer.

To use streaming heightmaps, do the following:
1) Set Generation Mode to streaming heightmap.
2) Set the Base Heightmap, a low resolution copy of the actual heightmap you want to use. It is used in places where the high-res copy isn't loaded.
3) Set the path to your high-res heightmap file. This is a standard PT heightmap file, same format you'd use as a Base Heightmap, or in normal Heightmap Generation Mode. Internally, the path is appended to Application.dataPath, after building you might want to change that (l.52 in StreamingHeightmap.cs). E.g. path to the included desertHeightmap would be "Planetary Terrain/Heightmaps/desertHeightmap.bytes".
4) Set Loaded Area Size, this is the size of the high-res section of the heightmap that will be kept in memory, where
(1, 1) would be the complete high res heightmap. A decent value would be (0.1, 0.1), depending on the size of your planet.
5) Set Reload Threshold to the threshold after which you want, where 1 is the planet's radius. A decent value would be 0.01.

For visualization purposes you can set Base Heightmap as an empty heightmap with zero elevation everywhere. This makes the loaded area visible.

Sorry for the inconvenience, will expand the sections in the docs!

 

Ahh, perfect, thanks

 

How is the height map scaling calculated? The default value is 0.02, what is that, a percentage of the radius? It also looks (from experiment) that the heightmap is only added to the radius, where I would expect the mid-level of the heightmap to correspond with the radius.

 

Yeah, height scale is max elevation as a percentage of radius. For simplicity it is always added, though you could easily change that.

 

I wish to position stuff like houses on the surface of my planet. I wrote a script where I provide the latitude and longitude, and this works nicely, however, I want to snap to the surface of the planet, by casting a ray from high altitude towards the center and detecting the collision, but this only works where the collider has been generated.
Can I..
a) enable colliders for all levels without much of a performance hit (maybe have them on a layer only used for this task)
b) detect when the collider under an object gets re-generated so I can do the raycast as the detail level changes for a position?
c) generate all colliders at maximum detail during loading, do the raycasting, save the results, and then discard the unneeded colliders?

There are probably a few other ways to go about this, so any suggestions would be really welcome. Right now I manually fly to the location, and adjust the height up and down until it looks right, but this is time consuming and breaks if I alter the heightmap.

One other thing that's kind of related, which I haven't looked at yet, is that I want to perform a raycast to a distant object, and detect when it goes behind the horizon and loses line-of-sight. This probably requires detailed colliders located on the horizon. I don't know what accuracy I need yet, but pretty accurate. Any ideas how to approach this?

 

As can you, since I think it is more natural to have highs and lows in the heightmap, deviating from the average planet radius

 

Regarding texturing, I am just looking for ideas for a rocky moon, which looks good both on the surface, and all the way up into space. I can sort of see how I would go about providing texture based purely on distance to the camera. Has anyone tried this and does it help? I'm also not entirely sure how to go about generating textures at different distances that would work well together.

 

a) I'm not sure about the performance hit when using colliders everywhere, just try the profiler and see for yourself if it is manageable.
b) Adding colliders is handled by QuadGameObjectPool.GetGameObject(), which is called in Quad.UpdateDistances(). You can also check if the quad you placed objects on is splitting (Quad.isSplitting), or add something to the end of the Quad.Split() coroutine.
c) Sure. Would not have optimal performance, but as long as you don't have to something every frame, you should be fine.

I generally try to stay out of the scene space for such calculations, as Raycast is slow. Have you tried using heightProvider.HeightAtXYZ to get the elevation, like in Planet.InstantiateOnPlanet()? Of course, it will not take the detail level into account, but might be worth a shot.

Your other problem is way harder to solve without using scene-space raycasting, in this case it's probably the best way. If your planets are fairly small and flat you could perhaps raycast against the scaled space copy?

 

Will add a define

 

There are the Fade Materials that fade between two textures based on distance, with the right textures and tuning it looks pretty good. I'm also thinking about adding some noise to a TextureProvider so that flat areas don't just have one uniform color anymore.

 

Is it possible there's a bug in the Fade shader? It looks to me like only the Tiling value from the near texture 0 is used for all other tiling values...

 

Works fine for me, just make sure to use Texture Scale instead of the usual Tiling and Offset fields.

 

Good new, the shader I have on the pack is fixed so I can put this on Quad but I don't know where on the Quad.cs to add the composent in question to allow shadow on this.

Thanks in advance for help.

 

Do you want to add a specific component to each quad that is being generated? You can attach the component to all quad GameObjects in Pools.cs, after line 117, e.g:

Code (CSharp):

1. if(rquad.GetComponent<SgtShadowLayer>() == null)
2.     rquad.AddComponent<SgtShadowLayer>();
3.  

 

Thank, is work (with and without "Hide Quads in Hierarchy").

 

I can confirm that everything works fine with one camera at a time (even assuming you switch cams for various reasons such as pilot vs panoramic, etc). For GPU instancing thousands of objects, that gets into an issue that isn't really exclusive to Planetary Terrain, its a floating origin issue.

This particular floating origin script is pretty flexible. If the impostor asteroids are parented to something, then just add that to object list. If they are always individual objects, then you could set an event at the max threshold where you swap to a single impostor such as a textured disk. Worse case, change the object array to a List, and just dynamically add all the objects to it.

I dunno how if the latter option would tax resources or not, I haven't added any asteroid fields so far. But I doubt there would be any show stoppers.

 

"..one camera at a time..."

But Planetary Terrain is not using at least two cameras (far - near) at a time?

 

I think that's what meant, as near and far are in the same place. PT also works fine with just one camera (just near), but then the viewing distance is limited by the zbuffer.

 

The case is there are two cameras. Using GPUInstancer asset, for example, you need to attach an script to every camera on scene to work properly and only one camera can be active at a time.
Another problem I see is with floating origin system. If I understand well, using it, the objects are repositioned around the user camera when they are too far from origin. I don't think it is the better way to create a realistic game world if the scenery objects change their position all the time.

 

Sorry, but both of those things are an absolute requirement if the game world is larger than say 50,000 units in radius, and you want to be able to see reasonably far. If you're planning for a world smaller than that, you can use PT with just on camera and without floating origin just fine.

The camera part should not be too much of an issue. You can perhaps set the near camera far plane to 10,000 or 20,000 units, and then have it as the active camera in GPU Instancer. Like this you would obviously only be able to see the instanced items from a distance of 10,000 or 20,000 units, but that shouldn't be an issue if the objects aren't too large.

I don't think floating origin would be much of an issue as well, depending on how low-level of an API GPU Instancer provides. You could set it up in such a way that coordinates are relative to quad positions, and then push quadPosition + relative as render coordinates to GPU Instancer. This is what the built-in foliage system does.

 

Planetary Terrain doesn't have to use far/near all the time. You can use one camera with a very far max distance. What I meant by 'using one camera at time' is that you have a main camera on your controller, and then you swap to a camera attached to the ship, or a freelook cam, or any other cam you'd use to change the player's perspective. Having multiple cameras (one active at a time) does not affect the planetary terrain scene negatively.

With scaled space, that is another story. I kind of went a different direction and just handle objects how I'd imagine a ship's sensors would work. I scan for any body within a certain range as one of several object types, and then apply appropriate actions to them, like instantiating a model for bodies or atmospheres, adjusting exposure or density, etc.

I only apply a scaling effect when traveling distances that are farther than that general range (outside of far orbital). And really, if this is for a space travel game, to traverse that kind of distance, you're going to be using a different method of propulsion that is much more powerful, making your visible scaling effect so brief, you could just simplify the process.

 

This is the project I'm working on:

I´m assessing if I will use PT. Now, the planet is a sculpted high poly sphere. I don't want to use a too big sphere-world because I get collision errors and other issues, and the floating origin system is not a good solution for me. As I said, I don't think it is the better way to create a realistic and credible game world if the scenery objects change their position all the time when they are too far from origin.

 

The game world doesn't look incredibly big, there might still be some rigidbody twitching and such far from the origin. Your judgement in the end if that's an issue or not. For a very large-scale game (solar system) with floating origin, check out Kerbal Space Program.

 

Have any of you guys tried landing on a realistically sized rotating planet?

I notice that my planets surface is moving at hundreds of meters per second at the equator, and even if I match velocity with it, the unity physics is having a very difficult time of it. My ship generally starts sliding across the terrain after landing. I've tried creating a fixed joint to the planet to hold it in place but this doesn't work as expected. I don't know what it does exactly, but definitely not what I expected.

Any suggestions?

edit: I originally thought this was an issue with unitys physics not handling the fact that the colliding objects were moving very quickly, however i did a test with a flat plane and a spaceship landing on it, moving linearly (not rotating) and there was no problems at much higher speeds. Is it something to do with the angular velocity, or the generated colliders?

 

Haven't looked into this much myself yet. The problem might be caused by the quads not having (kinematic) rigidbodies themselves (that would be very expensive though).
You could try writing a script that matches the rigidbodies velocity to the surface velocity. Just apply some force based on height and difference in velocity. That's how it works in real life, in the atmosphere, after all.

There's also a simple rotate around planet script included, you can set it to the same rotation speed as the planet and try if that works.

 

I am able to pilot my ship to a very soft landing, so the velocities are already matched to within 0.1m/s at the point of touchdown. I don't know why the result is a mess.