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.
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.
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
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?
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 - 3D Radar UI : Beta-2d July-22-2016 - Community Showcases - Unity Discussions
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:
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).
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.
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…
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
