TOZ Planet Renderer - Gamekit for generating procedural LOD Planet and Solar Systems

yup,i know what u meant. i was trying to say if that would be a point to make the package more optimized,turns out i realized it is optional to turn on the wildlife . it would be great if the Instantiate and AddComponent calls can split into multiple frames to process instead of doing all of them in one frame. i plan to use other solutions to manage the nature and wildlife movement,like using job system and burst.

 

Hey, i really like your package, great work. Kudos to you! However i was wondering if we can have a pregenerated planet for reference in the scene view in unity? Would that be possible with your package?

 

To be honest, if you check the wildlife generation function, i wrote it hastly and not very optimised at all. Spreading the generation on a few frames sound like a good idea. Ill check and implement it in the next version.
I prefer not to use any custom packages like burst to keep the code clean.

Initially we had this option as a pregenerated planet, but i found it useless and caching the whole planet breaks the point of being procedural and just increases the final exe size. The gizmos should give you an idea about the size of the planet. Or you could improve it yourself.

Please dont forget to leave an honest rating on the assetstore.

 

Due to popular demand, here is a sample magical floating origin script that you can attach to the Head prefab.
As this is just a sample, it only moves the celestial bodies, the Head prefab(and its root spaceship or the humanoid) and the navigation waypoints. You might want to add the nebulae or any other objects yourself if you want to improve.

Save it somewhere with the file name FloatingOrigin.cs and just attach it to the head prefab.
Using such a system will give you problems to deal with later on when you do pathfinding between celestial objects.(Which will require continuous pathfinding whenever the objects move)

EDIT: Floating origin is now included in the package starting from v2.0

 

Hello,

Working on the next update. Which brings semi multi-threaded planet objects creation(plants, trees, wildlife). While this might sound good news, its also bad news that the amount of planets on 1 scene will be limited.
So, id like to hear your ideas.

Would you prefer many planets to roam around in 1 scene? (like a solar system or something, with minimal planetary details like those "Elite Dangerous" planets)
or
Would you prefer 1-2 planets in 1 scene with many details? (You will have to load other scenes to traverse the universe and UNLOAD the current in order to empty some ram)

EDIT: Or shall we just keep it as is. (optional planet details)

Please tell me what you think.

 

Okay, the next update is ready and ill submit it the following weekend.

New update is a minor one mostly regarding the nature and wildlife creation optimisations.

*Added another LOD level, (max is now 7) to decrease planetary visibility range
*Every planet now has a pooling system for nature objects, this means increased loading times but faster runtime placement, user also has to limit the visible planets per scene (to prevent much ram usage) as out of the box there is no limitation coded.
*Pooling system has also the extra benefit of not using GC as often as before thus results in increased FPS and minimised heap.
*Multi-threaded lod generation is now optional.

 

Sorry for delay, but just finished the 2.0 update and submitting to the store now. It may take a few days for it to show up.

This update brings alot and i mean alot of optimisations, package is now 10x faster plus the above mentioned new features. The most important for me is Garbage collectors duty is not as heavy as before now, and that means speed.

In this demo, i used a big scale, so use the radar to find where mars and other planets are.

Happy holidays!

 

The 2.0 update is online, you can download now.

There is the new hovercar thing, on the demo, disable the spacecraft and enable the hovercar and see how it works out.
Controls are WASD for movement, QE for rotation on Y Axis, RF for up and down.

Also, as i didnt have time for documentation yet, there is also this new thing but you might easily miss it. The celestial bodies scale down when you are further away from them proportional to their diameters. Relevant piece of code is in PlanetBase.cs file between the lines 219-226

Another important aspect is, the culling angle is now calculated from the eye distance to horizon on planet, which is a small optimisation, could be more accurate if we calculated the distance with the spherical arc but currently it calculates with a straight line.
If you need it to be perfect with the arc value, relevant functions are inside PlanetUtil.cs and GeomUtil.cs files.

 

There is this important aspect about 2 camera setups using unity which is about the shadows fading. This can be fixed by editing the UnityShadowLibrary.cginc file. (Beware that this is a core file)

Open the mentioned script and change the function UnityComputeShadowFade() at line around 322 into the following:

Code (CSharp):

1. half UnityComputeShadowFade(float fadeDist)
2. {
3.     if(fadeDist < 6.0)
4.         return 0;
5.     else
6.         return saturate(fadeDist * _LightShadowData.z + _LightShadowData.w);
7. }

This will remove the shadow fading artifact from your near camera.
If you also use CloseFit shadows instead of stablefit shadows (in your quality settings), it will also remove the spherical clipping of the near camera shadows.

 

Here is a video of what the new demo scene looks like

 

i can tell there r a lot of improvements going on here, also i want to point out is , when the player enter the earth and the trees showed up ,the frame rate dropped significantly , i checked that is the lookatcamera.cs causing this, basically 10k calls update doing the lookat camera thing, i think it can be turned into a shader thing ,let the GPU to work this ,would be way more fast

 

It is actually caused by the 10k raycasts for calculating the exact position on the surface.

About the billboarding;
The way unity does it with trees and its own billboard renderer can only calculate the up vector to be (0,1,0) in a shader which can be a constant.
Thats why we can NOT use the billboard renderer or any shader based solution as we are on a planet and up vector is a variable and needs to be calculated individually. Forexample, try using a speedtree with billboard renderer active, and you will see the orientation is always looking up. Thats why i have the lookat camera thing.

The cached object generation already improved the problem atleast 100%, what more we can do is; also cache the calculated positions OR use the datamap to calculate position instead of a raycast but then, the required cache size increases insanely and garbage collector starts working and lag comes back.
i cant think of anything else to improve it and im open to ideas though.

Anyways at the end, you need to find a balance between the quantity and frame rate.

 

I would like to confirm, then the created planets are not showed and visible in the editor window (not play mode)?

 

The planets are shown with a green gizmo sphere in edit mode, they will be generated on Awake when in play mode.
This is to prevent unnecessary caching and easing on the garbage collector.

 

The problem is then it is very difficult and imprecise to position gameobjects like buildings on the planet surface. This is the reason I discarded Planetary terrain asset for my project.

 

To position buildings or anything else on the planet, you use the "PlanetHasStation" and "PlanetHasWildlife" or "PlanetHasNature" properties. Then your selected prefabs will be positioned on the planet randomly. But the random seed is the planet id, so every run of your game, the random will be the same position.

You surely dont want to position every little thing on a planetary scale or even a solar system scale by hand?!?
And if you really must, you can check the Planet.cs file and see how the station object is positioned, and PlanetTreeNode.cs file to see how wildlife and nature objects are positioned. Then you can surely write your own Awake function to position anything you want on any Latitude and longitude.

The relevant helper functions for latlon are in PlanetUtils.cs file.

 

Yes, not every little object as trees or rocks but I need precise position for buildings.
Thanks for the information.

 

One way of doing it would be:

*Check the PlanetaryObject.cs class, and make a copy of this class like "PlanetaryDetails.cs" or something.
*Add variables for latitude and longitude.

*Change the stationPrefab object in Planet.cs file to an array as PlanetaryDetails[] details;
*Change the CreateStation() function to recieve these latitude and longitude instead of the random ones, the height will be auto adjusted to the height anyways.

I will try to remember and add this feature for the next update.

 

TOZ PLANET RENDERER 2.1 is ready.

* Much faster, much much faster now.
* Shadow issue is solved, without tampering the original cginclude files.
* LOD generation is improved and optimised.
* Planetary objects (trees, nature..etc) are generated faster without visible hickups
* Various bugs fixed regarding lattitude and longitudes
* Various bugs fixed in general.
* Universe is scaled correctly now.

This update now brings the package to a stable state and i am proud that i can say the planet generation can compete with big titles like no man's sky or anything smiliar and even better than elite dangerous or the new starfield game's planets, which will bring a price increase.

BUY FROM ASSETSTORE

 

Just submitted the new v2.1 to the store, it will take a few days until its approved.

This new 2.1 is a major overhaul of everything, package is in one word "awesome" now, but some things i didnt want to rush out are missing in this one. However, i am preparing the 2.2 and will submit in a few weeks.

Documentation is also now online and its a work in progress.
Please remove the old version before importing the new one.

 

Last 2 days to get this package for 50% OFF. Get it from the ASSETSTORE