Space Exploration Engine - Procedural Planets, Ring Worlds, Huge Seamless Environments

The Space Exploration Engine lets you break down the walls of your game world. Your players can be walking around on a planet's surface one minute, and the next be stepping into a spacecraft and taking flight towards a nearby ring world. During their journey, the player might walk around inside their ship and interact with other physical objects. Or they might float outside their ship to carry out external repairs. All of this happens completely seamlessly.

You can use this thread to ask any questions or make any suggestions about this product.

Easy To Use

Drag and drop planets and ring worlds into your game world. Customise their size (no limit to how big you can make them), mass, terrain style, and more. A user guide explains how to use the asset, as well as explaining how it works for the curious.

Fully Customisable

With full source code and documentation, more advanced users can mould the engine to suit their exact requirements.

Target Any Hardware

The Space Exploration Engine can bring seamlessly traversable, life-size planets and ring worlds to just about any hardware that your players are likely to have. It doesn't require a fancy GPU, nor even a fast CPU on low settings.

Demo

The demo performs significantly better as a standalone application than in the web player. I personally recommend you download the appropriate standalone version. However, the web player version should give you an idea of what the engine can do for your game.

The planets in the demo are about the size of Earth, while the ring world has three times the radius of Earth.

WindowsStandalone:
https://drive.google.com/file/d/0B7VD0QSMox3GbE4xelBQNEdxeGM/view

Mac Standalone:
https://drive.google.com/file/d/0B7VD0QSMox3GTm5ZMWtmR3FXTUU/view

Linux Standalone:
https://drive.google.com/file/d/0B7VD0QSMox3GOGFkOXh3bTZRLVE/view


Product In Asset Store:
https://www.assetstore.unity3d.com/en/#!/content/30263

 

Hi!
First of all, this looks awesome with a lot of potential, so well done for that, but I was wondering if we would be able to look at the user guide before deciding to purchase the asset, for more information on how the system works inside of Unity.

Also, are there any specific features you have planned for future updates?
Keep up the good work!

 

Sure, I've attached the user guide. Hopefully that will give you an idea of how to integrate it into your project. If you have any further questions, just ask. I haven't got any updates planned at the moment.

 

Hi, just a quick question: you mention that you don't have any updates planned at the moment. But I was wondering if you are not going after the multi-threading that you mention at the demo. In my opinion, that would certainly be a game-changing feature for an asset that creates massive procedurally generated content. Hope you are still considering it.

 

Hey, I'm afraid I'm still on a long break from this project. Hopefully I'll get back to it soon, but I can't make any promises. On the bright side, the asset is fully functional in its current state. Multi-threading would allow more terrain detail to be generated than is available in the demo. But as it is, there is still plenty of cpu time available for other scripts (AI, etc). Unless you are travelling very fast near the surface of a planet, the cpu won't need to generate terrain during most frames.

 

is the terrain auto-generated or can I place objects on the planet to interact with?

 

The terrain is procedurally generated. You can also place objects on the terrain surface to interact with.

 

Hi there, my computer spec is pretty decent one: Intel(R) Xeon(R) CPU E3-1230 V2 @3.3 GHz, 8 Processors. 16 GB memory, GeForce GTX 660 Ti. I noticed a heavy lag as my ship going up, like 3 FPS. Is SEE trying to generate the whole planet, procedurally in runtime, at such height? If so, I would love to have a mix of procedural terrain generation, streamed terrains, and a 3D planet. My "best-case" scenario, for now, is that when my ship going up, I want to stop procedural terrain generation. I want to quickly swap the whole planet with a decent 3D planet model. Smooth transition is tricky. I don't know how to do it yet. And, as my ship going down, and landing on terrains, I want a mix of procedurally terrains with some streamed terrains. I will need to explore this pack for more, don't know if all of these above is doable or not. Overall, this SEE system is a hidden gem for sure.



The performance is a bit better with a Window build, instead of running it in Unity. As I get rid of my ship, my player hangs in the air, cannot move much. Overall, pretty funny and sad scene

 

Hi ikemen,

You're right, it doesn't run very well in the editor. It actually isn't due to terrain generation. It's because you're moving so fast that the terrain needs to move each frame. If you slow way down, the frame rate should return to normal. This should be less of an issue in Unity 5 as they've made it cheaper to move objects, but it's still a bit of an issue, mainly in the editor. It should run pretty smoothly when you build and run the project. What sort of frame rate are you getting when you run the build?

All the best,

Demian

 

Hi !
Very intresting asset!

whether it is possible to make changes in the script for chunks for make terrain with unique vertices.
I need a terrain with sharp edges.
thanks )

 

Hi, you mean you want a flat shaded style? Yes, that would be possible, but you would need to have strong programming skills and be willing to do some tedious work. If that sounds realistic, then I'd be happy to provide some guidance.

 

Yes!
I will be glad to read a short description of what i need to edit to be able to assess whether he make changes.
will check my skill too )
Thanks for quick answer!

 

And few questions
How i understand asset use double for Vector in Unity. Which can be a problem when interacting with others and their own scripts and assets?
how the force of gravity? just off in the distance or decreases smoothly?

 

You need to change the terrain generation code to generate 6 vertices for each terrain point. You also need to generate 6 normals for each terrain point, and work out how to systematically find 3 of the vertices that form a triangle with each normal in order to calculate the normal direction.

Probably worst of all, you will need to make triangle lists for the new vertex layout for each variation of detail. You need one triangle list for full detail, and 4 for reduced detail along each side (if one of the neighbouring terrain chunks has less detail), and 4 more for reduced detail along two adjacent sides (if two of the neighbouring terrain chunks have less detail).

There is a relatively easy way of generating all of these triangle lists, but it requires indexing the vertices in a particular order which, for some bizarre reason, negatively impacted the frame rate when I tried doing it that way a couple of years ago.

To be honest, it's a bit of a horrid job, which is why I haven't done it myself.

 

It uses doubles in the background, but you shouldn't need to know about that. You just use the normal Unity transform component (32 bit floats) and whenever my asset detects that the player has moved too far from the origin, it moves the origin back to the player and updates the transforms of every gameobject to reflect the change.

If you are worried that this might be a problem for your particular needs, you can give me description of your plans and I'll tell you if I think it might be a problem.

Gravity is calculated based on the distance to the closest planet and the mass of that planet. So yes, it decreases smoothly.

 

DemianT, thanks for detailed explanation and answers.
I expected something like that. I tested some time ago a similar solution on free asset for procedural Planet and it turned out well. (screen attached for any case)
But I am confused by all that is happening within your Asset in double and i will need re-write some standard unity functions.
whether there is the possibility to evaluate the code and my ability to modify at some example? can you send a piece of code generation vertices and mesh for expecting?
or example, l guess the appearance of problems in using 3D radar systems in your scene - http://forum.unity3d.com/threads/3d-radar-ui-beta-2c-jan-6-2016.79163/

 

Hi DemianT,
thank you very much for your answers and file - go to study and try to change )

 

Greetings! This looks fantastic. I have been working on my own solution for some time, with limited results. I think my mistake was working from an icosphere. It just way over complicates the geometry and I do not have a strong maths background to slice it into chunks.

With that, I have a couple of questions hopefully you can answer before I purchase:
1. Does PW_OriginLeash provide the "virtual" position of the player after it resets to origin? As in, when they go off exploring the vastness of space, does it provide where they /should be/ (like even if it's in a string), or will I need to work that out myself? Basically, I have an approach set up to deal with interstellar and intergallactic scales, but those features will need to be aware of actual, full-scale numbers to pick surrounding stars/galaxies out of the noise and project them around the player (if you're curious, I'll basically be doing something akin to 3D skyboxes in Source Engine).

2. Have you made the noise functions at least somewhat modular, such that I can use noise algorithms other than Perlin (and also apply additional erosion functions, etc)? Again, any guidance here would be appreciated. If you did it the way I hope, I should be able to fairly easily pass in a different function (that provides a range of expected values, which I would assume is -1.0 to 1.0) with minimal modification.

3. Following from #2, I would like to make actual visitable stars (and also gas giants, etc). Since you say these planets can be of arbitrary size, is there any reason I couldn't use one for the job, simply applying Cellular Square noise for the "terrain", and tying the light source to that game object? I guess what I'm asking, is: can they REALLY be of arbitrary size, because stars can get to the size of small solar systems in real life. I would assume that the Leashes take care of this, but wanted to make sure...

4. How fast are planets generated (on a modest modern CPU, say i5 2500k)? Will I need/want to hide generation times behind warp effects or anything?

5. It is likely that I'm going to mature your project quite heavily within my own (as I mentioned above, I already have an approach to deal with larger scales, just as an example). Would you be interested in collaborating at all, and adding my work in? I was planning to eventually sell whatever I ended up with on the store anyway, but it would make more sense to somehow tie the projects together. Alternatively, I can sell my bits as "compatible with", but that's not as user friendly.

I think that is all for now. I'm sure I will have more once I get your asset up and running, but any advice/guidance/etc you can provide is greatly appreciated.

Regards

 

Hi, thanks for the questions.

1. Am I correct in understanding that you want to access the positions of objects relative to a global, unchanging origin, even after the origin that Unity knows about has shifted? This information isn't currently provided, but it should be easy to add this functionality. I'd be happy to provide guidance.

2. When a new chunk of terrain is being created, a function is called for each vertex, taking as a parameter the direction of the vertex from the centre of the planet, and returning the 'height' that vertex should have relative to the radius of the planet. You can use any terrain generation algorithm as long as it only depends on the direction of each vertex. In other words, your algorithm needs to be able to calculate the position of each vertex independently of other vertices. I seem to remember that there are some terrain generation algorithms that don't satisfy this property, in which case, things could get more complicated, or even impossible, with my engine.

Also, bear in mind that terrain generation is performed on the CPU, so some more complex terrain generation algorithms may be infeasible performance wise.

3. Yes, they can be of arbitrary size. But if you need to go close to the surface, then it can get CPU intensive. If you are using huge 'planets' for stars, then you should be fine, unless you are planning star 'landings' or something.

4. The demo should give you an idea of this. If you are warping directly to the surface of a planet, then it could take around 10 seconds to finish generating the terrain. If you are warping near a planet but still in space, then it will be faster, maybe a second or so.

5. Yes, I'd be open to discussing that.

All the best

 

Many thanks for the swift reply!

Quick comments in reply:
1. Yes, correct. I can probably achieve the same end result, however, if I just very carefully track the position in inter-stellar/galactic space in tandem with local solar system space.

2. Sounds semi-similar to how I was trying to approach it w/ the icosphere, only I generated the base sphere first, then modulated the position of the vertices via noise to make terrain (again, this is fine, but I couldn't work out a good way to slice the sphere into LoD-able chunks at any stage of this). I have some vertex shader-based noise functions that may get the job done in this case, as it sounds slightly different when dealing with a projected cube.

3. I mean, it would be neat to do landing on stars for just general sight seeing (like Space Engine), but I just can't even imagine how that would be remotely desirable or realistic in a game context, so I will probably not even worry about terrain (texture or color instead) and rather just kill the player at a certain distance before too much detail is needed. Just wanted to be 100% sure there was no extreme upper limit.

4. No, I would not plan on warping directly surfaces. It was just hard to tell from the demo when the moment the planets began being generated, to the time the scene was visible. Wasn't sure how much other stuff might also be getting taken care of in the background prior to even getting to those steps.

5. Excellent... I am in the process of porting my inter-stellar/galactic prototype into Unity from Panda3D. Give me a few weeks (maybe month or two, as I work for a living) and I will be in touch to show you something tangible!

Again, thank you for your time! I will probably dust off the old credit card by end of the week and give you some money!

UPDATE: Have a beer on me

For anyone concerned, I can confirm that yes: This works in Unity 5 as advertised!

 

I seem to have hit a bit of a snafu. Here is a screenshot:
http://imgur.com/a/zDgdi
As you can see, the speeds are wonky. At that time, I was still close to the red planet; just pitched up.The perceived speed seems normal, but the distance countdown for the main thrusters stays stuck at 50000, and the speeds increase indefinitely.

I have not yet had a chance to troubleshoot/investigate, but thought I would point this out, in case you need to make a bug fix and/or can give me a little insight on where to look.

This was built in Unity 5...Tried both x86 and x86_64

EDIT: Forgot to mention, it seems like the main thrusters were never going to kick on due to this glitch. I flew away from the red planet for quite a long time, and that message never went away, and my speed never increased (outside of the obviously wrong numbers on the GUI)

I'll be able to have a closer look in an hour or two from this writing.

EDIT2: Hmm...seems to function normally in the game preview (running the project from within the editor). I am stumped now...I feel like I'm doing something wrong.

 

That sounds very strange. I've never heard anything like that before. Which version of Unity 5 are you using? Have you made any changes at all? Did you download it into an empty project?

 

Unity version is 5.3.5f1

I just tried creating a fresh project to be sure that I hadn't inadvertently changed anything, but still having the issue.

It doesn't make any sense at all that it would work normally in the preview, but get weird after it's built. Compiler issue? Unity bug? I have not changed anything there - running a completely stock install of Unity + VisualStudio.

EDIT: It is worth noting, that I am fairly new to Unity, so it very well could be something simple that I'm overlooking...

UPDATE: Realized I was quite a ways behind on Unity updates, so updated (had only just installed to this PC (Windows 10) a few weeks ago). No change in the condition.. Works perfectly in editor preview, but once built, I get wonky speeds and my distance from the planet does not update. I don't see anything obvious wrong in the code, so I remain stumped.

 

I've just tested it with V5.3.6 and I'm getting the same problem. Additionally, the frame rate is very low. Sorry about that. I'll look into it now.

UPDATE: it seems to be to do with tags not getting imported correctly, or rather, with imported tags getting messed up after building the project for the first time. Hopefully I'll find a solution tomorrow.

 

Thank you kind sir! I look forward to your findings. Now that I have some direction, I'll have a look tonight as well.

Yea, I did notice a drop in frame rates on the very latest version of Unity. If push comes to shove, I can roll back to an older version of Unity. I'm really not bothred either way...I'm just grateful not to have to spend 1000 hours figuring out my own solution to landing on planets

 

Hey, yeah, it was the tags. Send me your email and I'll send you a working version.

 

Sent you a PM yesterday...did yu get it?

 

Ah, I didn't get an email notification. I'll send it to you now.

 

Quick question - Do you have any advice about the Player object movement to make it come to a stop? Seems it's always pulled down hill by gravity (also bounces off the surface, making it even worse), thus always moving. I've tried a handful of ideas to implement better behavior (including using SuperCharacterController, which had the same symptoms), to no avail.

That is way down the list of things for me to work on, so in the mean time, I've cooked up a script to deal with it temporarily. Had pasted it, but its got some bug I'll have to work out before it's fit for public consumption.

 

You might want to check out 'NonPhysicsMove', included in this asset. It is similar the script you posted earlier, but it has more movement options. It might be useful during development.

Regarding the rigidbody character controller, I tried fiddling around with frictions and forces but couldn't find any simple way round the problem. If you turn up friction high enough that you don't fall down slopes, then you also won't be able to move up them (except by jumping/jetpacking). That is unless you turn up the movement force, but then you'll move too fast when not walking against an incline. I suppose some complex solution might be possible, perhaps involving modifying the movement force based on the slope of the terrain.

For walking around on planets, you could use an 'off-the-shelf' character controller, providing it supports changing of its 'up' direction and teleporting while keeping its velocity. When it comes to using spacecraft, things can get more complicated depending on the requirements of the game. If the ships don't have interiors, and the player just 'teleports' into controlling them, then it's pretty straightforward. Otherwise, you need to decide how you're going to deal with transitioning between inside and outside ships. In the demo, I've gone for a completely seamless approach, which relies on a rigidbody character controller in order to work.

If you want to use a different character controller, there are some difficulties. Unless you have an extremely sophisticated character controller, you probably won't want the model the player is in to be moving and rotating while the player is trying to walk around. What you can do is move the outside world and keep the ship still. But then you'll need to work out how to deal with potential collisions between the ship and the outside world. I'd recommend this approach providing gameplay requirements allow for it e.g. you can avoid collisions between the ship and the external world, or you don't need the ship to behave like a rigidbody.

Alternatively, you could let the ship move, but teleport the player to a stationary model of the ship's interior. Then you would need some sort of clever camera system to work out what the player should be able to see out of the windows.

 

Thanks for the insights!

I did see the non-phyiscs controller, but didn't mess with it too much and I don't recall what turned me off to it now, so I'll take a closer look. The reason my script failed was because I didn't think about the fact that the gravity would be trying to keep the "feet" aimed at the planet. Huge derp on my part...I may just apply it to a raw camera, but I'll have to tweak the OriginLeash to work with it.

For dealing with on-planet stopping, I do have an idea right now, which is when no movement buttons are being pressed, to forcibly decelerate the player and then forcibly keep their velocity at 0 until they press a movement button again. Basically, faked friction. Also, would have to forcibly limit their top speed, as I notice that not only are you continuously adding force to the rigid body (when a button is pressed), but it's getting added to again by the gravity, so you end up skating/bouncing across the surface at crazy impossible speeds. Haven't worked out a way to do this yet, probably due to my lack of experience with Unity, but I have no doubt there is some way to do it. Will let you know if/when we come up with something.

Ships will be an Everest for us....We're generating them procedurally, so it remains to be seen if we're going to bother with interiors or not, but I love that aspect in the demo so hopefully we can figure out a way to do it without adding 20 years development time!

Anyway, thanks again! Great food for thought. Having a blast working with this so far - money well spent!

EDIT: As far as forcibly stopping the player, I'm now finding a treasure trove of results on google that for some reason weren't returning the other night when I looked, so the future is bright!

 

Actually it isn't as simple as enabling nonPhysicsMove. Firstly, you'll also need to disable velocityOriginLeash, gravityManager and LimitVelocityNearSurface. Those scripts were made with the demo in mind and need to be modified depending on the requirements of your game. For the purposes of simple free-flying, they aren't needed at all.

Secondly, you also need to disable the 'Demo' game object, as that enables the jetpack controller even after you disable it in the inspector.

Thirdly, (and I'll include this in an update, but you can do it now if you want), in the script 'PW_ManageTerrainCollider.cs', you need to add a static class variable to control whether or not terrain colliders should be used. Add the following line:

'public static bool MeshCollidersEnabled = <whateverYouWantItToBe>;'

And change the Update() function to:

Code (CSharp):

1. void Update () {
2.         if (MeshCollidersEnabled) {
3.             Transform ship = objectListManager.getShip ().transform;
4.             Vector3 shipPositionIn1Sec = ship.position + ship.GetComponent<Rigidbody> ().velocity;
5.             bool colliderActive = UpdateCollider (ship.position, shipBoundingRadius, shipPositionIn1Sec);
6.             if (!colliderActive) {
7.                 GameObject playerAvatar = objectListManager.getMainPlayerAvatar ();
8.                 if (playerAvatar) {
9.                     Transform playerAvatarT = playerAvatar.transform;
10.                     Vector3 playerPositionIn1Sec = playerAvatarT.position + playerAvatarT.GetComponent<Rigidbody> ().velocity;
11.                     UpdateCollider (playerAvatarT.position, playerBoundingRadius, playerPositionIn1Sec);
12.                 }
13.             }
14.         } else if(meshCollider.enabled) {
15.             meshCollider.enabled = false;
16.         }
17.     }

For the flying controller, you want mesh colliders to be disabled.

Note that, with regards to my previous post, this toggle could be used by a script to disable mesh colliders when the player starts moving inside a ship with a walkable interior. That way, the ship can be kept stationary while the external world moves without expensive mesh collider moving.

 

Awesome, thanks a million!

 

To anybody who may be stuck, it appears that

Code (csharp):

1. GetComponent<Rigidbody>().velocity = Vector3.zero;

Appears to be the magic seasoning to make my above idea work (fake friction).

For now, I've just bound that to a key, so we can move around on planets more easily for development use (while still having the full physics of the rigid body working), but in the future, I'll expand it to smoothly bring it to a stop, and hold it still until a movement key is pressed again. Oh, and also that alone will negate falling (y axis) as well - you just completely stop, but I believe that should be easy to overcome.

EDIT: I just double checked the user guide to make sure I didn't overlook anything related to the non physics move script, and i see there's no mention, so if I may humbly suggest, you should probably add your above instructions

EDIT2:
In Update() I added:

Code (csharp):

1. if(!Input.GetKey("w") && !Input.GetKey("s") && !Input.GetKey("a") && !Input.GetKey("d") && isGrounded) GetComponent<Rigidbody>().velocity = Vector3.zero;

I moved isGrounded to a private class variable.

That makes you stop as soon as you hit the ground, but allows normal falling/jumping. That's all I want (for now), mainly lacking nice deceleration. As it is now, it's a hard stop.

 

Thanks, yeah, I'll add that to the user guide.

Regarding your 'fake friction' idea, I tried something similar in the past but couldn't get it to work. Unfortunately I can't remember why. I may have just been being a bit stupid. Hopefully you will fare better!

 

So, I'm making some progress on the rest of my universe generator... Just went to drop a planet prefab into my scene (which is basically a stripped down demo scene with some extras & cameras reconfigured a bit) and well, you'll see by the screenshot that it hardly went swimmingly.

Any advice would be appreciated...I can't tell for sure, but it seems like the chunks are not always moving when the planet is shifted by the origin leash. It's kind of hard to see but those panels are actually floating above the planet - they are not simply misaligned.

It's also worth noting, that the demo scenes are working fine, and I am still using the same version of Unity I was before when you made that bug fix. So guessing something is wrong with my setup. Note there are 3 cameras now, and I hijacked the one you were using for the skybox (the stars you see under the planet are procedurally placed now & are real geometry you could fly to). Anyway, so maybe I screwed something up there w/ the cameras?

Also, I notice the planet does not shift properly sometimes, as in it moves away from me a bit when the origin leash does its magic.

EDIT: Forgot to mention, I'm also seeing crazy amounts of depth errors (I don't recall the correct technical term, but it most commonly happens if you put two surfaces too close together, so you'll see both of them glitching and fighting for the foreground - that's what it looks like to me).

 

I see you have a null reference exception. Could you check the details of that? Perhaps you've made a new project and the tags have been messed up again. Take a look at the 'taglet' objects. Do they have the right tags?

What are the functions of your 3 cameras? I can only see one in your scene heirachy.

 

Of course, now I can't reproduce the panels getting placed above the planet issue - no idea what I did to fix that.

Still getting mad depth issues, but I am thinking it may be related to the modified clipping planes of my new camera setup. I'm exploring that now. My hypothesis is that it's losing too much precision past a certain distance, and the way you have the cameras' clipping planes set up in the demo worked around it.

The new cameras basically just provide two additional frames of reference (FORs) to represent interstellar and intergalactic scales of the universe. This is needed mainly because an origin leash alone cannot quite compensate for both the extreme distances and speeds required to traverse true sizes/scales of the universe. At least I couldn't find any way to make it work, and it seemed like speed was the major issue. Doing it this way means I can put galaxies only a few units away from the camera and define 1 unity unit = 1mly (or whatever), then render that into the background; do the same for stars. Then whatever you're actually close to (and going slow enough to see) will get moved to the local FOR. This way, the biggest scales I ever have to worry about are solar systems, which the origin leash seems to have no problem with. EDIT: of course, I will still need to origin leash the other FORs.

Tags all look OK to my eyes. This scene is basically a copy of demogoodquality from the latest update you sent me. Then I just stripped out what I didn't need (namely the demo gameobject, ship, and all the text objects). Incidentally, the null reference exception was related to the ship (or lack thereof), but fixing that did not improve the situation.

But again: now it seems the planet panels are suddenly working fine (lining up correctly), and the planet is shifting with the origin leash normally, now so......*shrugs* i don't even know...

 

Ok, yea, my hypothesis was correct on the depth issue, so now it seems like all is solved. Thanks for listening, I guess? lol!

Will let you know if I run into the weird floating planet panels thing again, because I'm still not sure what happened.

 

The Windows Standalone link is broken.

 

Thanks for telling me. I've fixed it.

 

Hello!
It looks amazing! I am surprised to found such complex tool in the Asset Store.

I have a few questions about it:

1. If I understand right, when planets located far away from observer, it is just a small mesh, but after observer approached to planet, at some distance it turned into full size terrain mesh with MeshCollider component.
So I want to ask, this physical mesh, it is default Unity Terrain, or just a mest renderer with mesh collider component?
If it is Unity Terrain, it means that I can use all of its features, such as trees, grass and various utilities from the Asset Store, such as shaders, it is correct?

2. When I approached to planet and its is turned into physical surface, it is always rotates horizontally?
I mean, if I approached to planet from its south pole (from -Y axis), the world will be rotated so after landing, sky will be located at Y+ axis?
It is necessary in order to allow rigid-bodies to sleep on the surface.

Maybe I described my questions not too accurately. I will make a picture if necessary.

Also, would be nice if you will create another demonstration video from the Unity Editor. For example, you may show how to add new planets etc. It will answer on such and similar questions.
This asset is very expensive relative to most other assets in the Asset Store, so it would be nice to have more information.

Thanks.

 

Hi, thanks for your questions.

1. I'm afraid it's just a mesh renderer with a mesh collider component.

2. The planets don't rotate. The player rotates and the direction of gravity changes as the player moves around planets.

I guess a demonstration video might be a good idea. Anyway, for now, feel free to ask any other questions you might have.

 

DemianT, understood, thanks you for the fast reply! : )

 

It is possible to combine with Space Graphics Toolkit ?
Nice work else.

 

There's no built in support, so to combine with any of it's features would probably require a lot of work.

 

Ok. Thanks for the information.
Good luck and continuation for the next.

 

This looks like a really awesome asset!!! I hope to use is it for a game im making!

Is their a sale or student discounts for this asset?

Thanks,
Xalo

 

Hi Xalo,

I'm sorry, but I'm not planning any sale or student discount.

All the best

 

Hi @DemianT,

No problem!! Thank you!!

Cheers!
Xalo