Planetary Terrain

^^^ all of the above I just read looks excellent, exiguous, aubergine, zjp

henry, I've been doing some experimentation with trying to get more detail on the planets using threading and I think you should look into https://www.assetstore.unity3d.com/#/content/7285(LOOM) or something similar for threading.

your threads need to be parallel to the main thread for the LOD calcs/generation, not started each update.. by that time it's too late, especially if the camera is moving fast.. thus resulting in lag spikes during calculations..

EDIT: additionally, there should be an abort calcs, something based on cam.pos != last cam.pos. there's no sense in completing the calcs for the previous LOD level if I've already moved onto the next. that way you're always only calculating hwat you need to display based on the current camera pos. and not waiting for the queued surfaces to regenerate..

i'm also getting a weird view clipping/visibility thing going on:



I have it set for 8 levels of LOD at 64 res with 1 subdivide. so when I move the camera back, the black patches go away and are replaced with visible patches. i'll investigate further however I thought you might know right offhand what this was and where to go to address it

 

Hmm.. Today I bay this package and I think its ok
About radius of the planet. I thing it will be better to create mesh with small radius but height quality and hight LOD the make bigger planet with scaling all object.
If I do some mistakes with writing am sorry.

 

seeding is used to generate the noise.. same seed, same noise.. try it memorize your planet, copy the seed, hit random look at the planet to see the changes, paste in the old seed and voila, old planet back

here's where this is cool (and an oversimplified example): once you have a universe created with all your planets, store the seeds (and any other pertinent data: radius etc) in a database.. then when ready (and/or networking) pull the seeds from the database and regenerate the planets. like a planet factory of sorts

this cuts down the size of deployment etc

 

i'm aware of that general fact. i was refering to the specific usage of the seed. as the perlinnoise class has no variable for a seed. thats why i ask how it is used (offest maybe?). when dealing with simplex noise some time ago i used the seed to feed unitys rng with it and then fill the value table from the seed randomly.

i think the video linked by zjp is not his own work but an example on what he is trying to achieve with planetary terrain. at least i have understand it this way.

 

Absolutely. My goal is to make a planet that looks like the video. Many works to achieve that.

 

Planet Radius is 90000 and position -2000000.
Camera Near Point is 1 Far is 1e+10x7. Mesh resolution 128 subdivisions 8, LOD 10 Levels with 1Lvl is 10.

Sorry for wideo quality little problem with codec. In play mode it not lag and animation look's normal.

 

The planets surface looks a bit blurry and undefined? No texture detail?

 

Not yet but I will do some thing with this.

 

Maybe some one know ... do I find some asset like camera but with dynamic parameters of Clipping Planes.
Some one ask .. for what?
When I create planet bigest then unity plan (100000 units) then I have problem with floating point.
Of course when I change in Cipping plan -> Near from 0.01 to 1 every think's ok (when am far away from planet) other way it dosn't look's good.
But when am create planet with radius for eg. 45000000 = 45000 km it's not enough.
So my idea is to create or if exist put in some script or object like camera with dynamic clipping plan parameter who look's only to planet and change clipping plane to higher when am far away and low when am close.

Right now I create a planet with 90000 radius in scale 1000 and Clipping planes -> near parameter is 1000
when camera is -1.585e+08 u ( 158500 km) from object, of course camera scale is 1 u scale.

 

@OP

Any news about the compatility with RTP?
You should contact the developer this tool because it is profitable for both of you.

Btw, when you talked about export meshes I was thinking about something more generic: export to obj format with one texture by element. The result would used with ANY 3D/GameEngine tool. Do not forget to add an XML file containing the position and rotation of all the exported meshes.

Many shaders will be used with this solution :
Example :
http://forum.unity3d.com/threads/192711-VPaint-Advanced-Vertex-Painting-Released
http://forum.unity3d.com/threads/206516-Relief-Terrain-Pack-(RTP)-v3-on-AssetStore
https://www.assetstore.unity3d.com/#/content/9822
https://www.assetstore.unity3d.com/#/content/12085

 

Nice work! I this this could be useful to a lot of people!

The values in the "value range" are actual values the node used to generate the preview image. The values normally should be between -1 and 1 but there are some cases where they might go over those limits, such as modifying the "gain" value in the generators or using ADD operator and so forth. I have considered adding a normalization function that would keep the values in the range if so desired.

The seeds are used as an offset in the generator like you suspected.

Code (csharp):

1.  
2. float value = ((float)PerlinNoise.Noise((position.x + seed) * freq, (position.y + seed) * freq, (position.z + seed) * freq));
3.  

This code can be found in the FBM-class at PlanetaryTerrain/Scripts/Nodes/Generators.

 

I agree the threading should handle fast moving cameras better and there shouldn't be such long queues forming. Thanks for the suggestions, I will look in to improving the system.

The surface is still there but it is completely black. I think this is related to the coordinates getting very small, the planet radius is too small for the LOD level. For example if the planet radius is 10, the LOD level 8 size could get very tiny. I am not sure what exactly causes this but you can remedy it by increasing the planet radius. I will look in to this as well!

 

What about the OBJ export, and
have a look here : http://forum.unity3d.com/threads/20...Store/page23?p=1462395&viewfull=1#post1462395

 

Hey, no news at this point but I am working on it. RTPv3 sure is a great terrain shader, the best I've seen around so support for it would be awesome. I am planning to make texture generation option where the user can select what textures are generated, for example height-, splat-, normal- and colormaps, and those are automatically forwarded to the shader upon generation.

I agree it would be useful to be able to export directly to obj. Currently you could use any mesh exporting tool available for Unity, I think there are some found in Unify wiki. I will look in to incorporating one in to the package though.

Thanks for the link and bringing it up in the discussion! Nice to see this has already been replied by the author!

 

This is what happens between intelligent people. I am sure you will find an arrangement.

About the obj exporter floating around the wiki, they export the mesh. Nothing for the textures.

 

I have contacted tomaszek. Thanks for pointing out the discussion!

 

You're welcome.

 

Hi.

Amazing work!
Some questions:

- Is it possible (speaking on performance) to use like 12 - 16 different planets (like a star system)? Does the LOD allows to render a very low version to be seen from another planets surface on sky?
- How Unity's shadow behave on surface? I've seen some problems on very large surfaces.
- About the generated colliders, is it precise enough to a vehicle travel trough the terrain, for example?

Thank!

 

Hey,

Yeah it is possible to have lots of planets, the LOD allows you to determine the lowest detail level and the level loading distances. Each planet will have 6 draw calls at lowest level (one for each side) and they will perform distance check at user defined intervals to see if higher LOD-level should be loaded. You could modify the check interval based on distance to minimize the processor load.

I have placed trees on the surface and haven't noticed problems with shadows, but for the examples I have kept the planet sizes relatively small (from radius of 10 to 1000). Each terrain patch is a separate mesh so you can control how large the individual surfaces are.

The colliders can be as precise as the renderer mesh. I think it is possible to drive a vehicle on the surface if the parameters are set correctly, but I would have to further test this to find out how well it works.

 

Nice, I will give it a try.
Thank you.

 

This is a good product.
Btw, maybe you can test your 'Impact Deformable' tool with Planetary?

 

Would be nice. But I guess that the Planetary Terrain keeps colliders cached at different LOD levels. If its true there is some adjustments to deform all these too. A nice thing to test on my January vacations.

 

Hey,

is there a way to add some vegetation-generation?

 

Excellent product, very happy with my purchase and looking forward to future updates.
Marstr - there is already vegetation generation, but it could probably use a bit of optimization

 

New Planet

 

@michaljabrzyk
nice work. can you tell us anything we should know about making pt + sgt work together? is it flawless or requires it manual work? i also aim at using both together and especially to see the rings through the atmosphere like in your example. i'm surprised that it works (out of the box?).

 

About PT + SGT.

Sorry for language mistake if such take place.

Set the Ambient Light in Edit ->Render Settings to black and dissable Fog.
If you will add other object's like ring's ..etc. turn on Pixel Shader 3 Emulation.
To create a planet (standard procedure like in tutorial) add a Planet object from PT asset (Planet PT is a base component who generate a planet terrain).
To create atmosfere add a SGT planet and put it in mesh and atmosfere , clounds...etc. If PT Planet radius is 32000 and Height Variation is for eg. 0.0075 then lowest point will be 31760 and highest 32240 .... so SGT Planet radius must be lower then 31760 but not equal (in my project is 30000). Planet PT and Planet SGT must have the same coordinates but in the other layer for eg. in my project PT planet is on PTP Layer and Atmosfere with SGT Planet is on a Atmosfere Layer. the same for the other object such as ring , asteroids ... etc.

Camera. Hire is litle problem with scale of the object's and floating point.
In my project used scale is 1:1000 where 1u is 1 meter. 1:1000 it means that 32000 planet radius is 32000 meters so it's 32 km. To use natural scale 1:1 you need a script who change floating point from for eg 0.01 when you are 5000u from planet surface to 1 when camera is 100000u from planet surface.
Witch modeling in natural scale 1:1 is important to create objects (surface and atmosfere) in lower scale like 1:1000 then change scale to 1:1 REMAMBER. If you create object's in scale 1:1 you will not see them in editor.

Good solution is add to all of your object's scaler script who change the scale of the large object when camera is closer to them. But what if you will need to put in to your planet some object in scale 1 (box package in a planet or ship's station)?...i don't have any idea's.
Different solution is use 3 different camera's for 3 different floating point.

What you use is your choice.

I chose the scales of 1:1 and flating point changer (experiment).

Camera move and look, rotation ...hire I use a scripts from SGT. I don't know how it works with the Auto Rotate script (not testet yet, but should works good if I you add your own script to dissable camera rotation script when camera is in some point from planet and enable Auto Rotation script [in theory]).

Light . Hire of course you must add a Light Source from SGT asset, and if you wish Antialising or some thing else [in my project Antialising DLAA Sharp].

Texturing. And that's the best.
Shader who is responsible for texturing planet terrain (PT Planet) is based on a Strumpy shader (jupi... ) so it's easy to add some are self materials or effect's. For now I try to writ some shader who can use bumped materials and create planet surface more diverse.

For eg. in theory human eye the human eye has a limited ability to distinguish details of distance
In addition, the atmosphere (shimmer) causes that the details are not good.

So you can give would be to write a shader that would add a lot of detail but on a small segment of the surface (maybe somethink like SubLOD that would only work for example, 100 feet above the planet surface{does not make sense to be active all the time when the camera is eg. 10 km above the surface} ).

But how to read a particular texture of the items on the PT Planet far have not even looked ... theory.

I would have liked to the diversity of the surface shader randomly added yet alpha
the textures such as in the range from 0.85 to 1,

I will say one thing.
This asset is the best solution for creating procedural planets.

And ed di the eddi the That's all folks.

HenryV great job and an awesome tool ,congratulations and regards.

 

What is the maximum allowed number of terrains used for planet, or is their number set by default and locked?

 

@michaljabrzyk
many thanks for your detailed explanation. i apreciate it and i think other users also as those 2 packages are the most obvious choices when aiming for space stuff.

 

First time in this thread, I must say that PT is hands down the best planetary terrain asset in the store at this point. It doesn't have everything yet, but the terrain is the best implementation I've seen so far.

As for my comment on PT and SGT, michaljabrzyk has the gist of it, he's dead on.

The basic setup with both PT and SGT is to create a planet from each asset. The PT planet serves as the main terrain surface while the SGT planet provides the extras, such as the atmosphere, orbit, clouds, rings, asteroids, etc. Basically, create both, make the SGT planet's radius slightly smaller than the PT planet (PT planet=1000, SGT=900, etc). The main issues I've run into are ones already part of each asset: PT's water shader and SGT's atmosphere and rings, etc. Sometimes SGT's rings pop through the SGT atmosphere. Dunno how to reliably fix that.

The worst of the two is PT's water shader. The issue is distance. The further the camera moves away from a PT planet with hydrosphere, the water shader begins to flicker. And it gets rapidly worse the further away you get. I'm not talking a long way away, I mean near-orbit distance. Everything else is fine.

A basic way to test this would be to create a planet with 1000 radius, continent module. Add a PT hydrosphere, set it also to scale 1000. This matches the planet radius, which looks okay up close on the planet surface. but as you zoom out into the atmosphere, and then into low orbit, it flickers terribly. Once you get out to orbit, then continue to move away from the planet until the sphere fills your screen, your planet becomes a blue flickering mess.

I don't know if this has something to do with my video card (I got the latest drivers for it from ATI last week), or how DX 9/11 works with Unity, or what.

Anyone got any ideas or known solutions to implement better water with PT? I'd love to eventually plug something like Suimono into my planets, but if this is a hardware limitation, or something worse, it may not be feasible.

 

Hi,

I added the exiguous's routine allowing to generate a MiniMap texture .

Planet.cs

Code (csharp):

1.  
2. public bool generateOnStart  = false;
3. public bool generateMiniMap  = false; // ************************ new !!!
4. public bool randomizeSeeds   = false;
5. public float seed = 0;
6.  

PlanetEditor.cs

Code (csharp):

1.  
2. SerializedProperty generateOnStart, randomizeSeeds, seed;
3. SerializedProperty generateMiniMap; // ************************ new !!!
4.  

Code (csharp):

1.  
2. seed = serializedObject.FindProperty("seed");
3. generateMiniMap = serializedObject.FindProperty("generateMiniMap"); // ************************ new !!!
4.  

Code (csharp):

1.  
2. if(GUILayout.Button("Rnd", GUILayout.Width(90f))) {
3.     seed.floatValue = (float)UnityEngine.Random.Range(-100000, 100000);
4. }
5. EditorGUILayout.EndHorizontal();
6. // ************************ new !!!
7. EditorGUILayout.Space();
8. EditorGUILayout.BeginHorizontal();
9. generateMiniMap.boolValue = EditorGUILayout.Toggle("Generate Mini Map", generateMiniMap.boolValue);
10. EditorGUILayout.EndHorizontal();
11. EditorGUILayout.Space();
12. // ************************ new !!!
13.  

Code (csharp):

1.  
2. private void Generate(Planet planet)
3. {
4.     float progress = 1;
5.     float total = planet.subdivisions * planet.subdivisions * 6;
6.     planet.Generate(() => {
7.         EditorUtility.DisplayProgressBar("Planet generator", "Generating...", progress / total);
8.         progress++;
9.     });
10.     EditorUtility.ClearProgressBar();
11.    
12.     // exiguous ***************************************************************************************************
13.     // exiguous ***************************************************************************************************
14.     if(generateMiniMap.boolValue) // ************************ new !!!
15.     {
16.         int texwidth = 256; // be carreful with a large texture !!!!!
17.         // creates a rectangular heightmap with "distorted" poles from the planet, texture height is calculated from width
18.         int texheight = texwidth/2,ty, tx;
19.         Texture2D tex = new Texture2D(texwidth,texheight,TextureFormat.ARGB32, false);
20.         float x, y, z, polar, azimut, onebyty, onebytx, halfx, halfy, sinpolar, cospolar, height = 0.0f;
21.         onebytx = 1.0f / (float)texwidth;   // onebytx/y is an optimization to prevent recurring divisions
22.         onebyty = 1.0f / (float)texheight;
23.         halfx = onebytx * 0.5f;             // halfx/y is the width/height of a half pixel to calculate the midpoint of a pixel
24.         halfy = onebyty * 0.5f;
25.  
26.         progress = 1; // ************************ new !!!
27.         total    = texheight * texwidth; // ************************ new !!!
28.  
29.         for (ty = 0; ty < texheight; ++ty)
30.         {// calculate the 3d position of each pixel on the surface of a normalized sphere (radius 1)
31.             // description of spherical coordinate system (polar + azimut) can be found here: http://upload.wikimedia.org/wikipedia/commons/8/82/Sphericalcoordinates.svg and here http://en.wikipedia.org/wiki/Spherical_coordinate_system
32.             polar = ( (float)ty * onebyty + halfy ) * Mathf.PI;     // calculate the polar angle (between positive y in unity (northpole) and the line to the point in space), required in radians 0 to pi
33.             sinpolar = Mathf.Sin ( polar ); // cache these values as they are the same for each column in the next line
34.             cospolar = Mathf.Cos ( polar );
35.             for (tx = 0; tx < texwidth; ++tx)
36.             {
37.                 azimut = ( ( ( (float)tx * onebytx + halfx ) * 2.0f ) - 1.0f ) * Mathf.PI;      // calculate the azimut angle (between positive x axis and the line to the point in space), required in radians -pi to +pi,
38.                 x = sinpolar * Mathf.Cos ( azimut );
39.                 z = sinpolar * Mathf.Sin ( azimut );// this is y in the wikipedia formula but because unitys axis are differerent (y and z swapped) its changed here
40.                 y = cospolar;// this is z in the wikipedia formula but because unitys axis are differerent (y and z swapped) its changed here
41.                 height = planet.Terrain.module.GetValue(new Vector3(x, y, z));  // retrieve the height on the actual planet surface by passing the normalized position to the terrain module
42.                 tex.SetPixel(tx,texheight - ty - 1,new Color(height,height,height));    // the y direction needs to be reversed to match unity up (+y) equals texture up, otherwise the texture is y-reversed compared with the planet (maybe due to v-definition)
43.  
44.                 // add a progress bar // ************************ new !!!
45.                 EditorUtility.DisplayProgressBar("MiniMap Texture generation", "Generating...", progress / total);
46.                 progress++; // ************************ new !!!
47.             }
48.         }
49.         tex.Apply();    // apply the texture to make the changes persistent
50.         // exiguous ***************************************************************************************************
51.         // exiguous ***************************************************************************************************
52.  
53.         string fileName="Planetary_MiniMap.png";
54.  
55.         byte[] bytes = tex.EncodeToPNG();
56.         System.IO.FileStream   fs = new System.IO.FileStream(fileName,  System.IO.FileMode.Create);
57.         System.IO.BinaryWriter bw = new System.IO.BinaryWriter(fs);
58.         bw.Write(bytes);
59.         bw.Close();
60.         fs.Close();
61.        
62.         EditorUtility.ClearProgressBar();
63.     }
64. }
65.  
66.  

The result.






BTW, I have SPACE for Unity. I will do some tests with PT.

@Janpec.
You can change everything.

 

the issue with modifying the pt original files is when you do an update they are overwritten and thus your changes need to be manually reapplied. thats why i did it as extension method as it does'nt touch the original files and i suggested that henryv includes it into the package directly so it comes with an update. i claim no rights at the code (not even credit) as i have deduced it from the wikipedia formulas some time ago.

and i'm also interested in your findings about pt - space for unity interaction.

@Planerunner
thanks for sharing your experience. the problems with the water are not so important for me as most planets are dry/frozen anyway. could th flickering be related to z-fighting? maybe try to set the far clipping plane closer. i'm also not sure wether the (transparent) hydro-mesh writes to the z-buffer properly.

i think it would be good to transfer the discussion of interoperability and other packages to a separate thread so this one stays focused on pt itself. i'm just not sure about the correct section. gossip maybe? there could be done space related discussion and "presentation".
anyway sorry for derailing your thread henryv.

the top priority requested feature for me is craters. a planet/moon/asteroid simply does'nt look authentical without them.

i see a big flood of space related games incoming . if i just could spend more time on my project.

 

Indeed.

No pb.

Can't help too. I'm working on one sand planet for my project.

Do not forget caves.

 

nice job zjp
and thank you for the minimap code exiguous

@henry, another small thing I've done that seems to increase performance is setting the meshes to dynamic. it seems to keep the buffer locking to a minimum. so in the surface class, initialize method, I've put this:

Code (csharp):

1. // mesh
2.         if (this.mesh == null)
3.         {
4.             // create mesh filter
5.             MeshFilter meshFilter = (MeshFilter)gameObject.AddComponent(typeof(MeshFilter));
6.             this.mesh = meshFilter.sharedMesh = new Mesh();
7.  
8. //I thought I could bold something in a code block. guess not lol
9. //***********************************************
10.             mesh.MarkDynamic();
11.             meshFilter.sharedMesh.MarkDynamic();
12. //***********************************************
13.  
14.             // create mesh renderer
15.             gameObject.AddComponent(typeof(MeshRenderer));
16.             renderer.castShadows = true;
17.             renderer.receiveShadows = true;
18.             renderer.enabled = true;
19.         }

not sure if this is the right place to put it, but it does seem to help..

btw, a question: why not mark a single gameobject/mesh as dynamic and just recalc the LOD level onto that instead of creating children? couldn't some performance gains be made that way? not a critique just curious

i'm also kind of checking out threading and seeing what can be done..

my issue with performance is that i'd like to be able to get greater detail than i'm currently able to get without a huge perf hit. factor that in with other planets and it becomes a serious issue. i'm using this asset with SGT as well.

lastly, during my experimentations with my own spherized cube I made mine without the need for bands at the seams.. there seem to be a lot of wasted geometry inside of the spheres I *think* due to the way you are handling banding. i'm sure the back faces get culled however i'm not sure the front faces are being occluded which means the fps might be taking a small hit per LOD level.. I can send my code to look at if you like. it might help. shrug

 

Nice to see that you guys have been working with the asset!

A quick update about what I have been working on:

Craters
There will be a new "Cell"-noise generator that generates Cell/Worley-noise. This type of noise can be refined to generate spherical shapes that can then be used for the craters. The crater profile can be defined using a curve. (Note: the spheres look distorted in the Output-window because the texture is generated to resemble a spherical planet surface.)



Here is a "Moon" module created using different sizes of craters:



Rendered image using this module:



Texture generation
I am working on a set of nodes that would enable the textures to be generated using the same node graph with the mesh. The user can also define which textures are generated (for example: height-, color-, splat- and normalmap) and those are then forwarded to the shader. This would make it easier to use custom shaders for the terrain such as the RTP. More on this later!


Other than these I am looking in to erosion algorithms, improving the atmophere and water shaders, improving the tree and detail rendering, heightmap import and lots of little fixes!

Happy new year to everyone!

 

You're welcome

+1, and i noticed collision problems at each meshes intersection.

 

This sounds interesting.

Good results and very nice to see that you are testing how these assets work together!

Currently there is the PlacementHelper-script that can work as a basis but for large amounts of vegetation it should be optimized. I am looking in to improving the whole system.

The asset does not use the unity Terrain-objects (for clarification). The number of surfaces can be set by the user, please check my post on the first page of this thread or the _click here to see the manual_ for more details.

Thanks for the comment!

The water shader is problematic and it definitely needs some improvement. The issue with the flickering is z-fighting with the water and the terrain. That is the reason why I use multiple camera setup in the demos scenes. I am looking in to the problem and searching what would be the best way to implement the water!

Thanks, this is a nice finding! I will make some tests with it and implement it if it improves performance.

The reason for this is the mesh vertice limitation (around 65k vertices). Also it might get more complicated with many LOD levels and this way I can only calculate the relevant vertices. It is good that you ask because then I have to rethink it over and possible find some improvements.

I think some of the further detail could be achieved in the shader side, that is why I am looking in to texture generation and more support for more advanced shaders. But it is good to check if there is any improvement that could be made and please notify me if you find anything!

The reason for the bands is the different LOD-levels not matching up (when the other one has less vertices) and then it is possible for the bright atmosphere to peek through in some pixels (Please check my first post in the second page in this thread for more detail and pictures). Of course if there wasn't anything (bright) behind the surfaces there would be no need for them...

I have done some research on this and if I remember correctly, the way they did this in Kerbal Space Program is that they had some extra vertices in the edges that would stitch up the seams and therefore make them match perfectly. I decided to implement it this way because it is simpler.

I think that the few added vertices probably really aren't a performance drag in the scope of things, but I might do some more tests to see for sure. They sure are ugly down there but you're not supposed to be looking!

 

Hi Henry,

Thanks for the great work! You extension works pretty well.

I am having a little issue with lighting. I cannot seem to be able to use a point light. Directional Lights work perfectly, and with point lights I get an extreme gain effect:



Also the atmosphere shader seems to break because of the same reason...

Could you please assist?

Also, It might be useful to maintain the object layer of the planet if one is assigned when generating (sub) surfaces;

Planet.cs( after line 268 ) add:

Code (csharp):

1.  
2. t.layer = this.gameObject.layer;
3.  

and Surface.cs ( after line 817 ) add:

Code (csharp):

1.  
2. t.layer = this.gameObject.layer;
3.  

Thanks!!

 

i don't need them and i'm not sure they are easy to add with the heightmap based mesh. there are 2 packages in the asset store which allow for "holes" in standard terrain. maybe this can be adjusted to work with pt for your needs:
https://www.assetstore.unity3d.com/#/content/3004
https://www.assetstore.unity3d.com/#/content/8277

you are welcome.

what, you stole my idea with the craters? just kidding. looks awesome and the crater curve is nice. have made a review in the asset store.

do you have an expectation when the new version will go live?

i affiliate.

 

Happy New 2014 Year everyone !!!

 

But if numbers of terrains increase in whole planet does that affect performance in gameplay? I know that it will in editor, but not sure on gameplay part.
Ok another thing, how is gravity handled by default if we use planet system? By default gravity goes down in certain coordinate, is it possible to bound gravity to center of planet? Sorry if its bit stupid question

 

Here For the gravity.

 

Happy New Year everyone!

 

Hey, thanks for feedback and sorry for the delay!

It seems the lighting calculation in the shaders is indeed broken with the point lights. I think this is related to the shaders being made with Stumpy shader editor and the custom lighting functions are outdated. I will work on a fix for this and do an update as soon as possible!

This is a good observation and definitely should be added. Thanks for pointing it out!

 

Thanks for the nice review! I cannot give an exact estimate yet, there is still some research and improvements to be done before I am confident to make the update and also making fixes to the existing features takes some time. I will post updates on my progress here though and hopefully the new versions will be live soon!

 

It does affect performance but the system also unloads surfaces (or terrains) if they are far enough away from the player. The operations are multi-threaded so they can happen on the background and the performance hit wont be that noticeable and also there are options that give you more control on it (for example how many surface can be subdivided simultaneously). You can preview what performance could be like in the webplayer demos in the first post!

There has been lots of questions about the gravity. So currently there is "Gravity.cs"-script that adds a constant force towards the planet center to a object (with rigidbody) that the script is attached to. As far as I know this should be the same than what the default gravity does but this also adjusts the force direction to always point towards the planet center. You should of course also disable the default gravity because it always points to one direction and you cannot have that in a planetary scene like this.

Another setup I have considered is to have a sphere trigger around the planet that would add a force towards its center to each rigidbody that comes inside it. This is not currently included in the package but it should be easy to implement. I might add it soon though since there has been requests for something like this!

 

Hi,

I broke down, I bought it!

I already had a similar project, but it did not suit me.

Yours is almost perfect, thank you for your excellent work

Here is my first quick test " first person " : https://dl.dropboxusercontent.com/u/45391150/Web.html

 

Hey, I am glad you like it!

Your project looks very nice! Is that your own or a 3rd party atmosphere shader are you using? I have also started working on a improvement for my own shader and something like that would be nice. Though I am still aiming the atmosphere to be working for both Unity and Unity Pro.

 

thank you, for the atmosphere I did not invent anything, I use it to "SpaceGraphicsToolkit"

 

I noticed that when generating on start the meshes are defaulted to the default layer. Any chance we could get an options to set the layer of generated meshes?